hi team, can someone explain what the difference b...
# ask-questions
q
hi team, can someone explain what the difference between
RUN_VISUAL_EXPERIMENTS
@
edge
vs
browser
is?
s
If I understand what you're after: • edge: experiments are executed on the edge server (e.g., Cloudflare Worker, Fastly Compute, Lambda@Edge) before the response is sent to the user's browser. • browser: experiments are executed in the user's browser after the page has loaded.
a
Thanks very much @strong-mouse-55694! We have a Cloudflare edge worker set up for redirect experiments. We have a custom tracking callback that's fired to send off an experiment viewed event. We found that for visual editor experiments, if we have that set to browser, then there is a duplicate on the experiment viewed event. For now we've switched to edge for visual experiments and only allowing experiments on content that is served server-side, but ideally we'd have a way to allow redirect experiments to run on edge and visual editor experiments to run on browser without the experiment viewed double up. One thing we looked into to fix it is whether the experiment info that we get into a cloudflare KV store will have info about the experiment type and if we see it's a visual editor experiment we can stop the tracking callback from firing off the experiment viewed event but from what we can see the experiment info does not include that. Any ideas? Cheers! šŸ™ cc @quick-ability-87647
h
The tracking callback should only fire on the environment for which the experiment was run. Are you seeing it fire twice, both times on the front-end? Also, do the two tracking events have the same assigned variation and id (gbuuid typically)? If they are the same, then it's not really a problem because the events are de-duped during the experiment analysis.
a
Ooh they probably do have the same assigned variation and id @happy-autumn-40938 - i'd need to check at some point, we no longer have it set up to run browser experiments. When it fired twice, it was once from our custom tracking callback which we added in the edge worker. That one we added a 'source: growthbook-callback' field in the event so i know it's from the callback, while the second one that fired was client-side and didn't have that same source so i was guessing it was from the client side sdk...? but this doesn't kick in when we set the visual editor experiments to run on edge which is good but restricts the types of experiments we can run (i.e a button text change where the button is rendered client-side). If you're right that the events are de-duped then we can probably go back to having them run in browser if we want to. We are using managed warehouse in terms of where events are stored. Would you expect that I'd only see one experiment viewed event there or two but then only one would be part of the actual experiment's results? i.e. where can i cross-check that the event is indeed being de-duped? In any case, we're mainly doing redirect experiments as these are running via the edge worker before page load so are best in terms of user experience/performance.
h
In your warehouse (including our managed warehouse), each discrete experiment viewed event is logged to the events table. However, it is deduped in the experiment analysis queries. You can verify this by clicking the 3-dot menu in the "Results" tab and clicking "View Queries". You'll see a section of SQL that looks something like this:
Copy code
__experimentUnits AS (
    -- One row per user
    SELECT
      e.ga_user_pseudo_id AS ga_user_pseudo_id,
      (
        CASE
          WHEN count(distinct e.variation) > 1 THEN '__multiple__'
          ELSE max(e.variation)
        END
      ) AS variation,
      MIN(e.timestamp) AS first_exposure_timestamp
    FROM
      __experimentExposures e
    GROUP BY
      e.ga_user_pseudo_id
  ),
The "GROUP BY" ensures that only the first event is considered (and that multiple exposed users are excluded from analysis).
From an analysis standpoint, it's perfectly safe to run visual experiments as hybrid edge + browser. I have seen the occasional DOM hydration issue in certain frameworks, but those issues typically make themselves known immediately (sounds like it doesn't affect you).
a
Hey @happy-autumn-40938, thanks for this info - I can see the query you mentioned that is de-duping. So this is good to know - if the business have client-side visual editor experiments they want to run i'll update that we can do this without concern for the duplicate events šŸ‘ cc @quick-ability-87647