Render "original" variant when user has opted out of analytics?

[lukehorvat]

Hi. Cool lib, but I'm wondering how to handle the case where the user has opted out of analytics (either via a website's privacy settings, or an adblocker is preventing Optimize from loading).

In such a case, it would be nice to always render the "original" variant. I thought that setting the default prop on a variant might work, but it doesn't – nothing is rendered.

I came up with a solution that works, but it's ugly:

render() {
  const original = <p>Original</p>;

  return (
    <div>
      {user.isAnalyticsEnabled() ? (
        <Experiment name="my-test">
          <Variant default id="0">
            {original}
          </Variant>
          <Variant id="1">
            <p>Variant 1</p>
          </Variant>
        </Experiment>
      ) : (
        original
      )}
    </div>
  );
}

Could the lib handle this somehow? I think it's a pretty common case.

An imagined implementation:

import { Experiment } from 'react-google-optimize';

if (user.isAnalyticsEnabled()) {
  // Load gtag script
} else {
  Experiment.disabled = true; // Causes all experiments to render the 'default' variant
}

[zvictor]

#2 takes care of rendering the default variant if anything goes wrong, including Optimize never loading.

[lukehorvat]

Oh cool. That looks like a solid update. 👍

Although there's one thing that gives me pause:

• the loadingComponent (which is null by default) used to be rendered while the client was waiting for Optimize. The new behaviour is to only render loadingComponent if it's defined, otherwise the default variant is rendered instead.

Won't this cause a content flicker? While Optimize is loading, default will be rendered; once it loads, it will render a variant. Will there be some way to enforce "no rendering" while Optimize loads? I guess setting loadingComponent to an empty string would probably work...

[zvictor]

the problem with rendering a loading component is that Optimize might never load (being blocked or whatever) and then your loading component will be there forever.

in my application (a next.js app) we have the default values shown first from SSR and then they are replaced by the variant values once they are available. I find this approach better than showing a loading spinner because the spinner is more noticeable than e.g. a change in text.

[gustavobini]

We could define a time limit so in case Optimize does not load, we do not have an infinite loader. This way, we also do not experience the flicker effect.

…

On Thu, Jun 20, 2019, 11:05 zVictor ***@***.***> wrote: the problem with rendering a loading component is that Optimize might never load (being blocked or whatever) and then your loading component will be there forever. in my application (a next.js app) we have the default values shown first from SSR and then they are replaced by the variant values once they are available. I find this approach better than showing a loading spinner because the spinner is more noticeable than e.g. a change in text. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=ABQ3NEC2AF6WJNPG2D6MWMDP3OFCNA5CNFSM4HZM5AAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYFQNLY#issuecomment-504039087>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQ3NEGLCR35H4QN6IUVIVTP3OFCNANCNFSM4HZM5AAA> .

[lukehorvat]

We could define a time limit so in case Optimize does not load

Yeah, that's basically what Google's anti-flicker snippet does. 👍

Would be nice if you could make the timeout globally configurable, so you don't have configure it for each experiment. In cases where you don't load Optimize at all (e.g. because of the user's privacy settings), it would be nice to have the timeout always be zero.

[zvictor]

I disagree.

Imagine that you set 2s as timeout but Optimize takes 4s to load. During the initial 2s you have a loading spinner; from the second second to the forth second you have the default variant rendered; from the forth second onwards you have the designated variant rendered. In total you end up with 3 different renders, making it a creepy experience.

In short, there is no magical timeout you can define that can guarantee at the same time:

• to be long enough to avoid default from being rendered in between the spinner and the designated variant
• to be short enough to avoid a frustrating loading spinner for the opted out users

[gustavobini]

@zvictor I might have not been clear enough there. What I meant with the timeout is the following behaviour:

Say we have a 2s timeout and Optimize takes 4s to load, as in your example.

0s - loader component is rendered
2s - default component is rendered
3s and above - default component continues there.

To summarize: if Optimize does not load before the timeout, the experiment does not happen. This way, the user will not see different implementations of the same funcionality being rendered - seems like a good experience.

[zvictor]

I see your point. Locking the variant once the timeout is over is definitely better than changing it later.

My concern with the loading spinner then is that it can become a problem when implementing it in SSR; For that reason I would still make loadingComponent an opt-in option instead of rendering null when it's not defined, as it used to be.

My suggestion is that we merge #2 as it is and we start a new PR to improve loading/timeout support.