Retrospective user recognition

[vklimontovich]

We have different ways to identify user. The way that always works relies on cookies. For some users, other ids can be known (through id() call). Example:

• event1: anonymousId=1
• event2: anonymousId=1
• event3: anonymousId=1, email=a@b.com
• event4: anonymousId=1, email=a@b.com

Right after event3 we can amend event1 and event2 and add email=a@b.com

Proposed architecture (highlevel):

• Do not support all storages, support only storages where modifications are available (like ReplacingMergeTree in ClickHouse).
• Once event3 happened, we need to go to statemanager (see below) and check if the particular pair has been processed.
• If not, "pair" should get to queue
• Once queue worker get to the "pair", it should get all events with anonymousId=1 and UPDATE records.

Possible ideas for state manager and queue:

• Standalone postgress (assume that we won't have many "pair" events).
• Redis (they have pub/sub)
• Reuse destination. Probably bad idea, since most destinations are not suited well for KV operations

[clementgalopin]

Hi guys, this feature is really interesting and much needed, when are you planing to add it for PostgreSQL?

[vklimontovich]

Hi @clementgalopin ! Once it will be available, it will work for most destinations, including postgres. It's currently in the making, the ETA is mid-Jan

[xtreding]

Hi @clementgalopin! We are happy to announce that this feature has already been released (v1.27.0)! Read more about configuration.