Hi, We have

anonymous_id

(device_id) from web that can map to

customer_id

when users log in. Our existing join table handles 1:1 ID mappings across systems perfectly (

customer_id ↔ other_id_1 ↔ other_id_2)

. The problem: We now need to handle m:1 relationships (multiple

anonymous_id

→ one

customer_id

). I created a separate join table for

anonymous_id ↔ customer_id

, but metrics that depend on other IDs (e.g.,

customer_id ↔ other_id_1 ↔ other_id_2

) don't work with this approach. Question: Should we create one consolidated table with all ID combinations (

anonymous_id ↔ customer_id ↔ other_id_1 ↔ other_id_2)

? Will GrowthBook handle the necessary grouping/distincting across all these IDs correctly?

Yes – you should definitely create a single consolidated join table that contains all possible ID mappings (

anonymous_id ↔ customer_id ↔ other_id_1 ↔ other_id_2

). This will allow GrowthBook to resolve user identities consistently across systems, regardless of which ID appears in the exposure or metric tables.

handling metrics across an anon -> logged in divide is tricky. Generally we recommend keeping them separate and then using that same table you have to join across the divide. You may have to throw away multiply exposed users once you figure out that it was the same user after the fact. You can use a different id on exposure than on analysis if you need - just be careful with the implications of this.

Thanks Serhii and Graham. I agree that for the most part it's best to have anon as a separate thing but it would be nice to also be able to see conversions downstream. For the most part we expect to have a 1:1 relationship for anon -> known but ofc. need to have the tooling in case we end up with m:1. My takeaway is that I should have everything in one join table and duplicates should be fine but I might end up with a lot of multiple exposed users (as expected), right? Or did you mean that it's best to keep the join table as is

customer_id ↔ other_id_1 ↔ other_id_2

and then have metrics that just work for anon, @fresh-football-47124? I have separate exposure queries for the anon and known - but it uses the same underlying table, just with a different ID column. The join table is modelled - so I can make that into whatever shape best serves the cause