Most brands that have quiz data cannot build one segment from it.
The integration went live, the answers are arriving, and nobody can act on them. That is not two problems. The transport is the easy part and the smallest part, and treating it as the project is why the data lands in a shape the segment builder cannot see.
1,569 words · about seven minutes at 240 words a minute
An on-site quiz is not a lead-capture form. It is the cheapest instrument a consumer brand has for learning what somebody wants before they have bought anything — and the revenue does not come from the quiz. It comes from what the program does with the answers for the next two years.
Which is why the failure is so quiet. The quiz converts. The answers arrive. Somebody opens the segment builder to make the thing the quiz was commissioned for — everyone who said their main concern was X and has not bought the product we recommend for X — and the fields are not in the dropdown. Not missing from the profile. Visible on the profile, absent from the dropdown.
At that point the integration is signed off, the invoice is paid, and the brand has quiz data it cannot use. I have never seen this caught by the people who built it, because from inside the build everything worked.
Why the answers arrive unusable
Five platform behaviours cause almost all of it. None is a bug and none is negotiable; each one simply dictates a design decision that has to be made before anybody writes code.
| The constraint | What it does to you | What it forces |
|---|---|---|
| Only top-level event properties reach the segment builder | Nested answers are on the profile and invisible to segmentation | Flatten every field you intend to segment on. Nest only audit data. |
| Names and values are case-sensitive | Dry and dry are two different audiences, so counts come out quietly low | Enumerate values in advance and enforce them in transport, not in the quiz UI. |
| Renaming a property creates a new one | The original persists and orphans; removing it needs a support request | Freeze naming before launch. A rename is an incident, not an edit. |
| A profile property and an event property sharing a name collide | You lose the ability to segment on the event property | Two deliberately different conventions. Title Case on profiles, snake_case on events. |
| Dropdown values only appear once a value has been received | A valid answer nobody has given yet is invisible to whoever builds the segment | QA has to exercise every answer permutation, not a happy path. |
The one that costs most is the first, because it fails in the most reassuring way. The data is demonstrably there. You can open a profile and read it. It simply cannot be reached by the one tool whose job is reaching it.
State and history are different objects
The second structural error is writing one of these and not the other, and it is the one I see in otherwise competent builds.
A profile property is state: what is true about this person right now. It is overwritten on every write and keeps no history. An event is history: immutable, timestamped, append-only. Write properties alone and you can segment, but you cannot trigger a flow off completion, cannot see when somebody took the quiz, and cannot detect a retake or a changed answer. Write events alone and you can trigger, but everyday audience building gets fragile, because event conditions offer narrower operators than profile conditions do.
Both, always. The current answer goes to a property. What they answered, when, and how it changed goes to an event.1
The seam nobody owns
Everything above is solvable and mostly known. The reason it keeps happening anyway is not technical.
A quiz integration sits exactly on the seam between marketing and engineering. Marketing knows what segment it wants and does not know that nesting kills it. Engineering knows how to POST a payload and has no reason to care whether Quiz Skin Type is a top-level key. Both sides ship something correct by their own standard, and the defect lives in the gap between two correct pieces of work.
So the deliverable that actually prevents it is not code. It is a document that says, before the build starts, who owns the specification, who owns transport, who owns identity resolution, who signs off validation, and what has to be true before anybody may call it done. I write that document, and the line in it that does the most work is the smallest one: if we cannot name the segment or the flow a question will power, the question does not ship.
A 202 Accepted means the request was received. It does not mean the event was processed and attached correctly.
From the acceptance criteria in that standard
That distinction is the whole of validation. “The integration is live” is a developer’s statement about their code. Acceptance is somebody opening a live profile and a segment dropdown and confirming it with their eyes.
What to do with it on Monday
If you already have a quiz running, these are checks rather than a rebuild. The first one takes about ten minutes and settles whether you have a problem at all.
- Open the segment builder and try to build the segment the quiz was bought for. Not a simpler one. The actual one — stated concern, minus the people who already bought what you recommend for it. What tells you it worked: the fields appear in the dropdown and the count is plausible against your completion volume. If the count is oddly low, you have casing drift rather than a missing field.
- Build the audit segment: profiles with a completion event but missing the expected properties. What tells you it worked: it is empty. If it is not, the integration is partially failing and you have found out before your customers did.
- Check that consent was written as consent. Completing a quiz is not permission to market. Confirm the subscription carries a timestamp, a method and a source, rather than the profile simply having been added to a list. What tells you it worked: complaint and bounce rate isolated for quiz-acquired profiles look like the rest of your file, over the next thirty days.
- Take a retake end to end. Same person, different answers. What tells you it worked: one profile, updated properties, a second event, and no duplicate. If a retake silently overwrites with no event, you have no way to see a preference change, which is most of what the instrument was for.
Notes and sources
- The version property is the one most often left out and most often regretted. Without it, every segment built on a quiz answer silently breaks the day a question is reworded, and nothing alerts you — the segment simply starts returning fewer people. ↩