Stitching Window vs. the 30-Day Purchase Cycle
A B2B SaaS company enables identity stitching on its connection with a 7-day replay window and crm_id as the person namespace. Most anonymous visitors browse for 2–4 weeks before converting and logging in. After enabling stitching, 'People' drops 18% and 'Visits per Person' rises. The marketing team says the drop proves stitching is 'losing users.' The data architect suspects the opposite. A separate concern: some users log in on a personal device and a work laptop, and the CRM ID is the same but the ECID differs.
1. Is the 18% drop in People more likely a bug or an expected effect of stitching? Justify with the mechanics.
Read the worked answer
Most likely expected, not a bug. Stitching's job is to collapse multiple anonymous/device identities into one person once a known ID is observed. If previously each ECID counted as a separate person, enabling stitching reduces the People count by design - that's the point.
The 18% drop plus rising Visits per Person is the signature of correct deduplication: fewer distinct people, each now credited with the sessions that used to be split across devices.
Caveats to verify before declaring victory:
- Replay window (7 days) is shorter than the 2–4 week consideration cycle. A user who browses anonymously on day 1 and logs in on day 20 may not get stitched if the replay window doesn't reach back far enough. So the drop could be under-stitching, not over-stitching.
- Confirm the person namespace is
crm_idand that the anonymous events actually carry a linkable identifier within the window. - Check that the drop isn't concentrated in a segment that should have been stitched (e.g., known users) - that would indicate a config problem.
Recommendation: extend the replay window to cover the consideration cycle (e.g., 30 days) and re-measure. If People drops further, stitching is still catching up; if it stabilizes, 7 days was leaving value on the table.
2. Two devices, same CRM ID, different ECID. Explain how stitching resolves this and what could still go wrong.
Read the worked answer
Resolution: Both devices eventually present the same crm_id. Stitching keys on the person namespace (crm_id), so once each device's events are associated with that CRM ID, both ECIDs map to one person. The two device streams collapse into a single person timeline, and Visits/People reflect one person across two devices.
What can still go wrong:
- Timing within the replay window. If the work-laptop login happens more than 7 days after the personal-device anonymous activity, the earlier events may not be re-attributed. Extend the window.
- Conflicting IDs. If the CRM ID is shared (e.g., a team login) you'll over-stitch distinct humans into one person. Verify CRM ID is 1:1 with a human.
- Late-arriving identity. If the CRM ID arrives in a separate dataset that lags, stitching may run before the link is available; check dataset ordering and refresh.
- Pre-stitch vs post-stitch metrics. Historical Workspace reports built before stitching was enabled won't retroactively match; document the change date so stakeholders don't compare across it.
- Privacy/governance. Stitching across devices touches consent - confirm the CRM ID is permitted for stitching under the customer's consent state and data governance labels.