Using Provisional Selections

For cases where you don't know for sure whether you'll be able to actually display or deliver the selected experience.

When using the Conductrics API, you may sometimes encounter a situation when you want your Conductrics agent to select a variation for a visitor, but where you know it's possible that it won't be possible to actually display/render/provide the selected experience to the visitor.

Provisional Selections can be a nice answer for this type of situation. It does require an extra step in terms of development/integration on your side, so you'll probably only want to do your implementation this way when it's really needed.

Example Scenario

For instance, let's say you want to run an A/B test on a web page, where "A" means waiting 30 seconds before displaying an offer or prompt of some kind, and "B" means waiting 60 seconds. But you know that the user may very well move on before either 30 or 60 seconds elapse.

Rather than asking for a "normal" selection from your Conductrics agent when the page loads, which would get counted in the Conductrics reporting right away, in this scenario you could ask for a "provisional" A/B selection. You can then set a little timer in your code for 30 or 60 seconds accordingly, and then "confirm" the selection when it actually comes time to display the message.

This way, your Conductrics reporting will reflect only those visitors that you confirm were actually "entered" into the test. Our reporting and machine learning will reflect the goal/conversion rates for just the confirmed visitors. In contrast, those visitors that abandon the page before the 30 or 60 seconds elapse won't get counted in the reporting, and won't be considered by our predictive engine for "adaptive" selections in the future.

📘

This is just a fictitious example scenario for illustrative purposes. Your scenario may be very different, and it may not be appropriate to "hide" the "abandoned" selections from the test's statistics. Please feel free to contact Conductrics for guidance! :)

Working with Pending Selections

Let's continue playing around with the example scenario outlined above. Let's say the API code for the experiment is prompt-delay, so you would normally use the Local JS API or our Web Service get a selection from the agent, using an API Command that looks like this:

{"a": "prompt-delay"}

To instead make a pending selection, add an s (for "status") field with value p (for "pending") to the selection command:

{"a": "prompt-delay", "s":"p"}

The reply from Conductrics will look something like this:

{
  "items": [
    {
      "a": "prompt-delay",
      "c": "A",
      "p": "r",
      "md": {},
      "s": "p"
    }
  ],
  "sels": {"prompt-delay": "A"}
}

Note that this reply from Conductrics shows "s":"p", to reflect that the selection is still "pending", and doesn't "count" yet. It's still "hidden" from the statistics gathered by the agent.

Later, when you know you've actually displayed the prompt or message (or whatever you are showing or doing on your side), you should "confirm" the selection so that Conductrics knows it's now "for real" and should be reflected in our reporting and machine learning models. To do that, make a similar call to your agent, this time with a status of ok, like so:

{"a": "prompt-delay", "s":"ok"}

Conductrics will reply with something like:

{  
  "items": [  
    {  
      "a": "prompt-delay",  
      "c": "A",  
      "p": "s",  
      "md": {},  
      "s": "ok"  
    }  
  ],  
  "sels": {"prompt-delay": "A"}  
}

Note that the reply now includes a s of ok to match, which reflects that the selection is now considered "confirmed". The p field has also changed to s to reflect that the selection was made via the "sticky" Selection Policy, which preserves the prior selection assignment for the visitor.

The selection should shortly be reflected in the Conductrics reporting, and the agent will now accept/count any goals/conversions that may occur.

🚧

Goals for pending selections are ignored

A pending selection can't be rewarded with a goal event until the selection has been confirmed.

FAQs

Q: What if we ask for a pending selection, then ask for a pending selection again?
A: If you ask for a "pending" selection again from the same agent before confirming (perhaps in response to a page reload or something on the visitor's part), you'll get back the same variation, again with "s":"p" to indicate that the selection is still pending.

Q: What if we confirm a pending selection, then confirm it again?
A: Conductrics will reply with the same response it did after the first confirmation. The selection will not be double-counted in the reporting.

Q: What if we try to "confirm" a selection but there is no pending selection to confirm?
A: Conductrics will reply as if you made a "pending" selection request.

Q: What if we ask for a "pending" selection, then send a goal, then confirm the selection?
A: Conductrics will ignore any goals (aka conversion events) that you send while the selection is still pending. We do NOT retain the fact that the goal occurred in the interim. In such a case it would be up to you to remember that the goal occurred on your side, and send it to Conductrics after you confirm the selection. That said, if you're in this situation, it may be an indication that you shouldn't be using provisional selections in the first place. Please feel free to discuss with Conductrics.

Q: Can we use Provisional Selections with the V2 API?
A: If you're using the V2 Runtime API, you can use provisional selections by adding a status parameter to the query string, for example &status=p to get a "provisional" decision/selection. Then, to confirm the selection, make the same decision call again with &status=ok in the query string. You can also use a HTTP header called x-mpath-status with p or ok as the header value.

Q: What happens if we make Provisional Selections while also using Analytics Connectors?
A: When you ask for a provisional selection (by specifying "s":"p" as discussed above), the variation selection is not sent via the connector. If you later "confirm" the selection (by specifying "s":"ok"), the selection will then be sent via the connector. You can use this behavior as a workaround if you need a variation selection from Conductrics before you necessarily have the external ID (first get the variation as a provisional selection, then confirm it when you have the vid to provide). See also Analytics Connectors and Passing an External Visitor Identifier.

Q: What happens if Visitor Traits change between the initial selection and the confirmed selection?
A: By default, the Conductrics reporting will reflect the Custom Visitor Traits that the visitor had when the original "pending" selection was requested. If desired, you can go to an agent's Advanced Settings and set the Selections: Allow visitor traits to change on provisional selections option to True, in which case the Conductrics reporting will reflect the traits the visitor had at the time of confirmation. This can be helpful in cases where you want to get a "pending" selection to initialize your page/app, but don't yet have the visitor traits that you want the selection to be counted against in the Conductrics reporting.