Hey all! Great to be here. I asked this on the web...
# experimentation
m
Hey all! Great to be here. I asked this on the website support, but haven't gotten a response yet. Would like to test a URL redirect. Love that Growthbook has cloudflare integration. We want to run: domain.com/test to domain.com/ and explore.domain.com/url 50% / 50% The issue I'm running into is the 'original URL' automatically goes into the control, which we can't have happen. So far, the solution I'm hoping MAY work is to use the domain.com/test url, and do 3 redirects, an a (/test)/b(root)/c(subdomain) test, and just make the A test 0% of traffic. Would that still work? I asked the Growthbook AI in the documentation and it said that what I'm experiencing is normal and a limitation. But it seems what i'm proposing may work. Thoughts?
f
Hi
The exposure event happens on /test
m
Hey there! I should've added, I did create a cloudflare worker already too
f
are you worried that the traffic on your root domain will contaminate the control?
m
Partially. We can't use domain.com as our control because it gets a lot of organic traffic. We only want to run this experiment for paid traffic so that's why we were going to run it as a router. domain.com/test as the ad link then domain.com and explore.domain.com for a 50%/50% test
Is there something I'm missing or thinking wrong on?
f
yes, so if /test is only really visited by the traffic you want to expose
even if you then send them to a more public page
the test won't be contaminated by the traffic already there
ie, the exposure log happens on /test, not on the redirected page
or are you having trouble with the test implementation?
m
I really appreciate your help, thank you!! So that all makes sense and is exactly what I was anticipating. The Hangup I had was the experiment. When I entered in the URL domain.com /test it automatically made domain.com/test the control/variant A and it did not let me edit it. That's the thing that is confusing me.
f
oh, I see
let me check on that
m
Thank you so much!!
f
Yes, three way test is best
And set control to 0 as you suggested
m
Excellent.
Will do. Thank you so so much!!
@nutritious-notebook-68264 @fresh-football-47124 One final thing I'm more than likely missing. Flow as above. domain.com/test -> domain.com/test A Variant (0%) domain.com B Variant (50%) explore.domain.com C Variant (50%) Redirect at edge via Cloudflare/GB Worker SDK All is fine, BUT I have what I think is a weird timing/race conditiong thing. I use the redirect link, get hit with my variant (B or C) fine, BUT If i enter the same domain.com/test url in the same private browser, I get redirected AGAIN to the other variant (not always, but sometimes) However, after that, I never get moved to a new variant again. What I think is happening is the gbStickyBuckets cookie fires before the gbuuid, then the second one sees the gbuuid and is fine after that. So I think the flow should be gbuuid created, gbStickyBuckets created -> nothing changes. Variant cookie remains Instead, right now I think it's gbStickyBuckets created, then gbuuid, and on the same browser and redirect link, a new gbStickyBuckets is created. I've attached screenshots to show what I'm seeing. Notice the gbuuid remains stable, but after the second URL in the same browser, there is a new stickybuckets entry I don't see this in GB docs, but on the GB NPM docs, I see
EMIT_TRACE_HEADERS
could be the solution here? Does that sound right? Or could it be something else? I'd also love to hear best practices for firing this gbuuid at edge, while also having OneTrust Consent for the relevant states. (cali, etc) I initially just thought to exclude the consent required states, but I bet you may have a better solution. Thank you!
n
Hey @mysterious-salesmen-51192, since you're getting two different UUID values according to the cookie data, it seems like the edge worker is generating a new one on the second hit. It might be that the browser hasn't written the cookie at the time the next request fires. Maybe try setting
PERSIST_UUID=true
on the edge worker so the edge sets the cookie directly. It looks like
EMIT_TRACE_HEADERS
should be true by default, so that shouldn't make a difference.
m
appreciate it @nutritious-notebook-68264 I do already have persist_uuid on and set as true
so I don't know if that's it
The interesting thing is it does NOT generate anymore after the second one. Even if I try 10 more time s
@nutritious-notebook-68264 Update. Looks like emit trace headers fixed it. Still two gb sticky's but they are both the right one. shuld be all good
Thank you. Also - any thoughts on CMP/OneTrust usage for this edge cookie?
n
@mysterious-salesmen-51192 sorry for the delay getting back to you. Are you trying to make sure of the ordering of the experiment cookies and the user accepting OneTrust in states where you need the consent banner?
m
No problem @nutritious-notebook-68264, thanks for the response. And, yes that's correct.
n
Do you have
NO_AUTO_COOKIES="true"
set? I think the general idea would be preventing GrowthBook from persisting the
gbuuid
for users within the locales you're interested in, then explicitly setting it after consent.