Hi @camil132 !
Great idea to design this ahead, it’ll save you nightmares later 😅.
Topics, attributes, and tags each serve different purposes. Intercom generally recommends using a combination of all three.
But, the important caveat for your data warehouse goal is this: Topics work retroactively (Intercom re-scans your whole conversation history when you set one up), but if you ever change a topic's definition, your historical reporting can become inconsistent.That's a real problem if you're trying to build trend lines in a warehouse.
I would use tags for granular reporting and topics for organizing/routing workflows, since a stable conversation attribute (or tag) is what holds up for reporting purposes, while shifting topic definitions can throw off historical numbers. So basically use Topics to discover what's trending and to route/prioritize in the inbox, but let tags (applied consistently, either manually or via Workflow) be the thing you actually pipe downstream.
In terms of taxonomy. I haven’t worked specifically with Fintech but a few ideas here:
payment-failed, payment-declined, payment-duplicate, payment-delayed transfer-delayed, transfer-limit, transfer-failed card-lost, card-activation, card-decline kyc-pending, account-access, account-verification dispute-chargeback, dispute-unauthorized-txn fraud-suspected, fraud-confirmed fee-question, fee-dispute compliance-request
The category-reason naming convention (not free text, not emoji, not "misc") is what saves you later (truste me).
It’ll be what lets a warehouse query group by category prefix without regex gymnastics.
I'd also keep a separate orthogonal tag or two for things like escalated / vip, rather than baking severity into every category tag. That's exactly the kind of thing that turns into 40 near-duplicate tags in six months.
Pitfalls:
- Sprawl: limit tag creation to a couple of admins/leads, keep a one-page tag dictionary. Free-for-all creation is how
payment_failed / Payment Failed / pmt-fail all end up coexisting. - Inconsistent application: spot-check monthly via the Most used conversation tags chart drill-in, not just when something looks off.
- Reporting lag: tag reporting runs 24–36h behind. Don't build a near-real-time dashboard on it.
- Tag vs attribute: if a conversation can only be one thing (e.g. root cause), that's a single-select attribute, not a tag.
Getting it into the warehouse
Don't rely on the manual CSV route long-term.
Intercom has a dedicated Reporting Data Export API (enqueue a job, poll status, then download) that covers the Tags dataset alongside Conversations, Contacts, etc., which is the right tool for a recurring pipe into Snowflake/BigQuery rather than the browser-based Dataset export (which caps at 10,000 rows for instant download and emails you larger files). Just double check that’s available on your plan.
Docs worth checking out:
Hope this helps!