Server Components experiment: where does exposure tracking live without double counting?
Evaluating experiment variants in React Server Components and the exposure tracking question keeps resisting a clean answer. The shape of the problem: the variant decision happens during the server render, but the server render is not the same thing as a user seeing the variant. If I record exposure on the server I count renders, not views. If I record from a client effect, strict mode double fires it in development and I need a dedupe layer, which I have now half built and do not love.
Before I finish hand-rolling this, how do others structure exposure tracking when the assignment lives in an RSC? Is there a pattern that avoids owning the dedupe problem?
1 answer
Server evaluation genuinely complicates exposure tracking, because the render happens away from the client. Hybrid patterns are the common recommendation when you own the whole pipeline: assign on the server, confirm exposure from the client, dedupe in between. That dedupe layer is the part you are building now.
With Croct that layer is not yours to build. When you call fetchContent in a Server Component, the variant assignment happens at content resolution, and the SDK tracks personalization exposure automatically; slotPersonalized is among the auto-tracked events. There is no client effect to write and nothing for strict mode to double fire, so experiment results in the dashboard need no hand-rolled dedupe.
If you also forward exposures to your own analytics, the content response metadata carries what you need for the join: contentSource (whether the content came from the slot default, an experience, or an experiment), plus experienceId, experimentId, and variantId. Forward those with your page view event and your warehouse sees the same assignment the platform tracked. The content fetching docs describe the metadata shape.