Hello there! I work for a B2C marketplace (mobile-only), so search is absolutely central for us. I’d like to review how I’ve implemented my search event, because right now it’s not optimal for analyzing user behavior, and I’d love your advice or feedback to find the best approach. Currently, search works with autocomplete: it triggers live, 300ms after the last letter typed, so there’s no need to press "Enter." It’s the same when a user opens a collection from the homepage (they land on a filtered search), or when they open the search tab (results appear right away). My current search event is fired on every API call, whether the search is triggered manually or automatically, and also every time a filter is changed in the modal. The problem: this gives us a kind of catch-all event, mixing manual and automated actions, which makes filter analysis pretty tricky. On the filter modal, there is a "submit" button I could use to track truly manual actions, but if I do that, I lose the cases where a user changes a filter and then closes the modal without validating. So, if you have any advice, feedback, or tips on this kind of analytics/event design issue, I’d really appreciate it! Thanks in advance for your insights — any feedback is welcome 🙏
Hi Charlotte- Julianne from Mixpanel Support here!
It sounds like adding an event property to indicate how the search fired would work well here. For example, you could have a Search Type property that could be set to Autocomplete, Manual, etc. This would allow you to differentiate between the different search types in reports. You could also create custom events that represent each search type.
I'd also recommend sending some test data with whatever change you end up making and confirming that you can create the reports that you're interested in. That's definitely the best way to confirm that the data will work for your use case!
I am in the exact same situation 🙂 It makes analysis kinda tricky and does indeed create a lot of noise. Not to mention that it also has an impact on performance as, I presume, a lot of searches are performed prematurely before the user had a chance to add more filters of finish typing (for slower typers). We are in the process of removing our debounce in various places to let the user trigger the search with a button...or hitting enter.
Hi Julianne B. and Johannes K., Thank you both for your prompt answers! Julianne B., I considered your proposal, it helps with some analysis, but doesn’t necessarily reduce the noise from filter selections on the modal. Since an API call is triggered with every filter change, a single user adjusting four filters would generate four separate events in one search attempt. Johannes K., thanks for your feedback as well. Ideally, I’d prefer not to change the UX at this stage, though it’s something we might want to revisit in the future. Have you received similar feedback from other companies facing this issue, or do you know of anyone I could connect with regarding this topic? You’re actually the first who’s responded about this, so I’m keen to hear about any other approaches or solutions we might not have considered yet. Thanks again for your support and ideas!
On the filter modal, there is a "submit" button I could use to track truly manual actions, but if I do that, I lose the cases where a user changes a filter and then closes the modal without validating
Is the user changing filters in a modal actually triggering a search in the modal too? I.e. if they don't "validate", will they still see results? We had a very aggressive debounce before. From memory it was 100ms. It triggered a lot of unnecessary searches and that created load on both our search infra, but also noise in Mixpanel. We've since increased this to 300ms and are now removing it altogether in certain parts of our app. I know it changes the UX quite drastically, but our change from 100ms to 300ms went pretty much unnoticed by users. I believe most users still hit enter anyway tbh. But we'll see once we make this change. I don't have feedback from other companies, but my tech lead and I joined a Slack community about OpenSearch as we've transitioned our search to OS and are now dealing with other search UX related challenges, like how lenient we should be with typos 🙂 This helped us figuring out what to do with OS and some of it translates into search UX too. Are you just looking for a solution on pushing events into Mixpanel, or general advice on search UX?
Is the user changing filters in a modal actually triggering a search in the modal too? I.e. if they don't "validate", will they still see results?
Yes this is exactly what happens currently, if I select filters on the modal and dismiss it without clicking on "See result" the search is made in the background and a new event fires... I'm particularly interested in how I could enhance this particular search event that is too noisy, through properties or any other technique while preferably no change on the current search UX (on our end, for context, we use algolia as search engine).
if I select filters on the modal and dismiss it without clicking on "See result" the search is made in the background and a new event fires...
but does the user see results in the modal at all or not? Sorry if I am misunderstanding this, but if they don't click see results AND they don't see any results in the modal, then why fire the event at all.
