Smart Asset Utilization
Outbound
Where outbound content contains a smart asset, other than a goal or advanced smart asset, content is inserted appropriately in accordance with the smart asset’s content elements list. RPI works through the list of content elements, starting at Content 1 and moving down the list. Each is checked in turn to determine whether a recipient qualifies to receive the content defined at the content element. Content is served by the first content element at which a recipient qualifies to receive it.
Determination of applicability at a content element is carried out in accordance with the smart asset type:
Attribute smart asset: the content is applicable if the recipient’s attribute value matches one of the content element’s configured attribute values.
Audience segment smart asset: the content is applicable if the recipient was targeted within an audience segment matching one of the content element’s listed segment names.
Rule smart asset: the content is applicable if the recipient is targeted by the content element’s selection rule or realtime decision.
Model smart asset: the content is applicable if the recipient falls within a model project band.
Default content, where provided, is served where no match occurs; if no default content is specified, no content is delivered. If a content element itself is configured with another smart asset, the rules in the nested smart asset are themselves executed to determine asset applicability.
If the smart asset is executed in Batch Outbound mode, content applicability is determined at interaction workflow execution, prior to message delivery. This means, e.g. in the case of an email, that email content will remain the same, no matter how many times viewed by a recipient.
If the smart asset is executed in outbound realtime mode, content applicability is determined using the RPI Realtime service. This means, e.g. in the case of an email, that email content can be varied dynamically when viewed a number of times by a recipient (subject to any stickiness settings).
Note that a runtime validation error will be raised at interaction execution if attempting to execute a workflow containing a smart asset using outbound realtime, when system configuration setting EnableRPIRealtimeServices is set to False, and when RealtimeAPIAddress has not been configured.
Smart assets used in outbound realtime mode are published automatically at interaction execution. When a smart asset contains local image content, that content is published to the Default smart asset location, as defined at an external content provider. If this property has not been set, a runtime validation error is raised.
Note that, if using outbound realtime at an email offer, certain email client applications may by default cache image content. This means that the dynamic variation of such content in the inbox may be compromised. This can be avoided by setting HTTP headers appropriately at the provider at which image content is hosted.
Inbound
Smart assets can be used, if appropriate, to vary content in an inbound contexts – for example, if hosted in an RPI landing or external page, or of invoked via the RPI Realtime API. Content applicability is determined as documented in the Smart Asset Utilization – Outbound section (note that the method by which content is deemed to be appropriate will vary according to asset type).
Goal Smart Asset Utilization
When a goal smart asset is published in a landing page, the following sequence of activities occur:
If Optimization mode is set to A/B/n test , the test phase begins immediately, and lasts for a period defined by the asset’s Test phase duration property. During this time, 100% of page visitors receive randomized content element content.
At end of the test phase, an initial test is performed. Testing is carried out by the Goal smart asset Monitor system task.
The number of goals achieved is considered in the context of number of impressions of each content element, thereby determining each piece of content’s relative efficacy in driving page visitors towards goal attainment. The content element with the highest goal conversion rate is selected as the winning index. Its conversion rate needs to be statistically better than the alternative assets, to a degree defined by its significance threshold.
The content element with the highest proportion of goals proportionate to the number of impressions is declared the winner.
If the result was not deemed to be statistically significant, the test phase continues, with a test being performed at a frequency accordant with the asset’s Reevaluation interval property. Random content elements continue to be served during this time
If a winner was declared, the content element in question is served to site visitors other than the holdout group, unless the result changes due to ongoing testing of the holdout group (see below).
When the initial test phase is complete, tests continue to be executed, with a random content element being served to a percentage of site visitors defined by the asset’s Holdout group property. Tests are performed at a frequency accordant with the asset’s Reevaluation interval
If the ongoing testing of the asset’s holdout group results in different content element being declared the winner, the new winner is thereafter served to site visitors (other than the holdout group).
Testing continues in this way for a period defined by the asset’s Monitoring duration property
Republishing the landing page in which the goal smart asset is utilized causes the asset to re-enter the test phase.
If Optimization mode is set to Machine Learning, RedPoint Interaction uses a machine learning algorithm to match a visitor's profile to the content element that is most likely to provide the highest goal conversion rate. Visitor profile and goal results data serve as inputs to the algorithm, which looks for patterns to facilitate matching the visitor's profile to the most appropriate content element to maximize the goal conversion rate.
Note that calls to the machine learning algorithm are managed by the Goal smart asset Monitor system task.
When a visitor is served a goal smart asset, if he or she refreshes or revisits the landing page, the same content element continues to be shown in the same browser on the same machine. The cookie used to persist the asset in this way lasts 24 hours, after which different content may be shown.
When a goal smart asset is published for use in an external web page, RedPoint Interaction uses A/B/n Testing or Machine Leaning to optimize content in the same way as if published in a RedPoint Interaction landing page. Note that, in this case, the asset’s goal is defined within the asset itself, and not within the page within which it is hosted.
Goal smart assets can only be nested in the following fil types:
Landing Page: a validation error is raised if a landing page contains a goal smart asset that is configured to be published externally.
HTML asset: a validation error is raised at a landing page if an HTML asset therein contains a goal smart asset that is configured to be published externally
Advanced Smart Asset Utilization
Advanced smart asset content is assessed for applicability in the same manner as other smart assets, with the following caveats:
Content applicability is considered on a variant basis, as, when an advanced smart asset is included in an offer or web page, it is a variant that is added to these contexts.
Message qualification rules are assessed as part of this process (for more information, please see that subject’s documentation).
Any message eligibility restrictions and allocation caps are also applied
File Metadata at Smart Assets
At audience definition validation, table [OfferHistory]_Content_Meta is created, with the following structure:
ChannelExecutionID
OfferCode
OfferTemplateInstanceID
AssetName
Metadata
A join can be made using on ChannelExecutionID and OfferCode. For more information on Audience Definitions, please see the Configuration documentation.
When an email offer contains one or more Batch Outbound-enabled smart assets with file metadata configured at the asset or content level, the table populated with metadata, which is stored in JSON format in the Metadata field - e.g.:
{"StringMeta":"Asset Meta","IntMeta":1.0,"DateMeta":null,"DecimalMeta":null}