Journal · identity
Identity stitching without over-collecting
A grocery delivery client in Bangkok had a guest checkout that never joined the logged-in order history. They blamed the warehouse load. The load was fine. The client event carried a device ID. The order confirmation event carried a user ID. Nothing in the stream said those two identifiers belonged to the same person after login.
Identity stitching is not a reason to put a national ID hash on a mobile event “just in case.” In-App Event Tracking Analytics needs a join key, not a biography. This note is the version we give Studio students before they invent a third identifier.
Three identifiers, not thirty properties
Most apps need: an anonymous ID that survives app reinstall only as far as the platform allows; a durable user ID issued after authentication; and a session or request ID for debugging a single journey. Everything else — email, phone, loyalty number — should live on a user table updated by the server, not on every Product.viewed payload.
When the guest becomes a user, fire a single Identity.aliased (or your house name for it) that contains both IDs and a timestamp. Downstream models can then attribute pre-login cart events without requiring those events to have known the user in advance.
What we refuse
Raw email on client events. Precise GPS when city is enough for the question being asked. Device fingerprinting packages whose only purpose is to outsmart a reset. Hashed national identifiers on the client, even “for fraud” — fraud checks belong on the server with a narrower audience.
A digital banking student once brought a payload that included a hashed citizen ID on a screen view. The legal team in the room went quiet. Quiet was the correct reaction. We removed it before the next store review. The join still worked with user ID plus anonymous ID.
PDPA-minded, not PDPA-theatre
Purpose limitation means you should be able to say why an identifier is on the event. “The CDP might need it later” is not a purpose. If marketing wants a richer profile, collect it in a flow that discloses that purpose, store it server-side, and join in the warehouse. Do not smuggle it through telemetry.
Thailand’s PDPA is the legal backdrop for our Bangkok studio; the same hygiene helps if you ship in other jurisdictions. The PDPA note goes further on notices and retention. Identity week is about not collecting what you cannot justify.
QA for the join
Before you celebrate a stitched funnel, check a sample of users who logged in mid-checkout. Count pre-login cart events that received a user ID after aliasing. If that count is zero, you do not have stitching; you have hope. Instrumentation Studio’s QA checklist includes this sample. It takes less than twenty minutes and saves a quarter of bad attribution.