Domain-Specific Signals and UI: The Real Work in Analytics (Full Transcript)
[00:00:00] Speaker 1: Most of our time is really spent on what additional ancillary signals we can add to the data once we have it and they're often Industry language and market specific. So, you know, we'll have a very specific Italian Spanish frustration model because the way Italians get frustrated is very different to the way English people get frustrated and we tried with generic models out of the box first But they we ended up with quite industry and language specific things So we spent a lot of time there and then a lot of time really in the UI I find the UI is just such a, it's all well and good having all your data looking nice in a database, but actually having that, our use cases are so spread, it's like people just come to customer operations directors and say, oh, it was an error last week with the promo code, were people annoyed and why? So you have to be able to just flexibly find that data, query it, summarize it, get the answers to that, and the questions can be anything. So our UI, it's underestimated, I think, in terms of making it both easy to use and flexible enough to answer all those use cases.
- Generic, out-of-the-box sentiment/frustration models often fail across languages and cultures; customization is required.
- Adding ancillary, domain-specific signals after data collection can significantly improve analytical usefulness.
- UI/UX is as important as the underlying data store because real-world questions are varied and ad hoc.
- Tools should support flexible querying and fast summarization for operational stakeholders (e.g., investigating incident-driven questions).