Documentation - Multi-destination CTA

Documentation - Multi-destinaton CTA

Find below information about the multi-destination CTA setup

Multi-destination CTA

Data collection - Multi-destination CTA

In order to setup the Multi-destination CTA in any of the modules cta, you first must generate some data in the multi-destination data collection.

In this data collection you will be able to setup as many "destinations" as you require, defining these just like different CTAs, the options you have are:

  • Destination ID: This id's purpose is to only be used in the multi-destination ad-hoc script that the landing requires. More details about the script below.
  • Text: Visual CTA text, we recommend all destinations share the same CTA, to avoid content switches when CTA destinations are being chosen.
  • Target blank: Allows to define if the CTA should open in a new tab or not.
  • Nofollow: Allows to define the CTA with a nofollow rel attribute.
  • External link: Just like in CTA, used to provide a full external URL.
  • Plan ID: Just like in CTA, used to provide a fever URL from a plan id.
  • UMT Dataset: Additional relationship to a UTM dataset configuration, if necessary.
Docs multi-destination collection
Docs multi-destination fields

CTA Relationship

Once you have some data in the multi-destinations data collection, in each CTA field in any module you can select the data you just created, through the relationship field.

This is all you need in the CMS to enable multi-destination. Below find the last details about the necessary ad-hoc script.

Docs multi-destination relationship

Destination logic

By default, when enabling a multi-destination setup from the CMS, a default destination logic is applied. This logic randomly selects the final destination based on the total number of configured destinations, with equal probability for each. For example:

  • 2 destinations → 50% probability each
  • 3 destinations → 33.3% probability each
  • N destinations → 1/N probability each

Custom Destination Logic

In case a custom developer destination logic is needed, the engineering-team must be involved, as a script has to be developer meeting the landing requirements to choose the final user destination through a script executed in client on-load.

For the devs:

  1. The script, being executed in the browser has access to all browser API's and data.
  2. The script has to be included into /landings-hbs/apps/**/src/virtual-modules/integrations/multiple-destination-cta.js
  3. The script has to export a method called getDestination, which receives an array of string destinations, being the provided ID through the CMS.

The image provided here is just a random example so you can see how this might be setup.

Technical details

  1. Renders all destination CTA's in the DOM.
  2. Only one of all destinations CTA is visibile, ever.
  3. In client, on-load, the ad-hoc script executes and through the CMS destination ID's we are able to identify each destination and conditionally choose it.
Docs multi-destination ad-hoc script