A/B Test using Custom Code modification to turn on feature flag | Community
Skip to main content
tomerk31559517
tomerk31559517
February 11, 2019

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

  • February 11, 2019
  • 1 reply
  • 4060 views

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

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    1 reply

    E
    Community Advisor
    evidanaCommunity Advisor
    Community Advisor
    February 11, 2019

    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
      tomerk31559517Author
      February 11, 2019

      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?

        E
        Community Advisor
        evidanaCommunity Advisor
        Community Advisor
        February 11, 2019

        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

          Terms & ConditionsAccessibility statement

          Loading footer...