A/B Test using Custom Code modification to turn on feature flag

[tomerk31559517]

Hello all,

My team is trying to run an AB test using 2 distinct flows throughout the form. We have collapsible sections and we're trying to figure out if having the topmost section always open would be better.

The way we've implemented this is by adding some control flow logic to see if the feature flag (named 'ALWAYS_SHOW_SECTION') is on the window and is true. The idea was to add a Custom Code modification to our A/B test in which we added

<script> window.ALWAYS_SHOW_SECTION = true; </script>

to the HEAD.

Locally, this strategy works, but when we try to do this through Adobe Target, it doesn't seem to change our logic.

Is this strategy sound? Does this strategy just not work on Adobe Target because of some asynchronous logic?

Thanks in advance

[Eric_Vidana]

Are you running your activity through target-global? Do you see the network call to Target resolve and that your offer is in the response. Is that script tag the only thing in the offer? The script should execute as it makes it way back onto the page. Maybe your form logic is running too early or are you referring to a form with multiple steps.

I see nothing wrong with trying to use Adobe Target that way. Sorry for the barrage of questions.

[tomerk31559517]

We've had some internal help with our test. It turns out that our test URL was too strict and that is why we weren't seeing the feature originally. We see it now, but there's still a race condition.

Setting the variable on the window is the only thing that happens in our custom code block.

If the user reloads, our javascript is cached, so it will likely execute before the adobe target variable is set. We've confirmed this by looking at our Chrome's network tab. The call to target starts before our code, but takes 128ms to download, whereas our cached code executes immediately.

Is there anything we can do to combat this? We've had a colleague recommend that instead of inserting the code this way, we can insert a span with some id and have our code look for the span instead. Thoughts?

[Eric_Vidana]

You can always get Target to respond back with one of 2 offers on a 50/50 split. Hide the content by default and let Target respond back with a function that does the rest of the work which is already defined on the page:

- Create local functions as mentioned below (on the page or local js)

- Hide form section entirely

- Call to Target

- A returns <script>unhideFormBlock()</script>

- B return <script> unhideAndCollapseFormBlock()</script>

- Can make sure function exist before calling it

If Target fails (there is an onError section of the getOffer) then choose one to be your non-Target experience. Can block Target in the network panel to test the fail case.

As a side note, this is what the page level mbox (mboxCreate) does on its own. Will hide the div until Target responds back:

<div class="mboxDefault">

  default content to replace by offer

</div>

<script>

  mboxCreate('mboxName','param1=value1','param2=value2');

</script>

at.js functions