Duplicate profiles and double-fired trial flow
A B2B SaaS company uses Klaviyo for trial and onboarding emails. Its product sends a custom event called Trial Started with properties plan_tier and trial_length. The event payload sometimes includes an email with different capitalization and sometimes includes an external_id; the website sign-up form creates a profile with email only. As a result, Klaviyo shows two profiles for the same person: one with the form properties and one with the trial event. The welcome flow fires twice for some users, and the segment 'Trial users on Pro' is 18% larger than the actual number of Pro trials in the product database. The engineering team wants to fix this by adding a new custom property, but the marketing team wants to clean up the existing profiles before next week's campaign. The company has 42,000 profiles and 6,500 trial events per month.
1. What are the likely causes of the duplicate profiles and incorrect segment counts? List the identifiers and event fields you would inspect.
Read the worked answer
Likely causes: inconsistent identifiers. The form creates a profile by email; the event may create or update a different profile because it carries an external_id or a differently cased email. Klaviyo may merge on email or external_id, but only when the identifiers match consistently. Inspect the form hidden fields, the API payload, the external_id value, email normalization, and whether plan_tier is sent as an event property or written to the profile. Also check if the segment uses event property plan_tier but the campaign expects profile property plan_tier. The 18% inflation suggests some trials are counted twice or some non-Pro trials are included.
2. How would you fix the tracking going forward and prevent the welcome flow from sending twice?
Read the worked answer
Going forward, enforce one canonical identifier: send external_id on every identify and event call, normalize email to lowercase and trim whitespace, and pass the same external_id from the sign-up form into the product. Update the event schema so plan_tier and trial_length are consistently named and typed. For the welcome flow, add a flow filter to skip profiles that have already received the welcome email or have been in the flow in the last 30 days. Test in a small cohort before backfilling. The reasoning is to make identity deterministic and stop flow re-entry, not just clean today's duplicates.
3. The campaign is in two days. What cleanup would you do now, and what would you defer? Explain the risk of each.
Read the worked answer
Immediate cleanup: export profiles with the same email or conflicting external_id, merge only where you can verify the same person, and exclude suspicious duplicates from next week's campaign. Do not delete profiles with event history. Defer the full API remediation and historical backfill until after the send if it risks breaking event tracking. The risk of merging incorrectly is losing event history or consent; the risk of doing nothing is sending duplicate emails and trusting a segment that is 18% too large. For the campaign, use a verified segment or a smaller engaged segment as a safety net.