Take Control of Server-side Forwarding: Using the [cm.ssf] Context Variable

[#1]

Data governance is a top priority for most digital marketing customers today.  Given that, customers need control over the data that gets forwarded to AAM from Adobe Analytics.  Implementing the [cm.ssf] context variable gives our customers the power to flag Analytics hits that should not be forwarded to AAM. 

Let’s discuss a couple of use cases where the [cm.ssf] context variable has been used as a solution.

User consent

This use case was related to GDPR and user consent.  If a site visitor has not provided consent, it is imperative that Analytics data not be forwarded to AAM.  Please note, this solution does not capture user consent, however, if the customer has a consent management system or process, the [cm.ssf] context variable can be set to control the data sent to AAM via SSF.   

Elimination of pixels on specific pages

This use case was related to eliminating all marketing pixels on specific pages of the site.  Adding conditional logic to the page code to set the [cm.ssf] context variable based on a list of page names (or URLs) will prevent SSF to AAM and all AAM pixels from firing.

Implementing the [cm.ssf] context variable will require an update to your Analytics page code, however, it does not require upgrading your AppMeasurement library (AppMeasurement version 1.5+ is a requirement for SSF).  While I am an advocate of using up-to-date code libraries (to take advantage of new features and bug fixes), in this instance I am using AM version 1.7 to ensure the solution will work for a client using an older library.

How the [cm.ssf] context variable works

On pages where Analytics data should be forwarded to AAM, the context data variable should be set to 0.  It’s worth noting this is the default behavior.  If the [cm.ssf] context variable is not implemented and SSF is implemented, data will be forwarded to AAM.

On pages where Analytics data should NOT be forwarded to AAM, the context data variable should be set to 1.  The data will still be collected in Analytics but no data from that page will be forwarded to AAM. 

The beauty of using a context variable is that this solution does not need to utilize an analytics variable.  However, if you decide at some future point in time, you’d like to configure reporting, you can always create a processing rule to map the context data to an analytics variable.  Refer to https://marketing.adobe.com/resources/help/en_US/analytics/audiences/ssf-gdpr.html for additional detail.

The details below illustrate how I implemented this solution on a sample website.   

How to implement [cm.ssf] context variable

I’ve created 2 sample pages: test_ssf.html and page2.html.  A few details about my 2-page website setup-

Both pages include:

•  Data layer a data layer object named UDO. 

To simulate user consent, I’ve added a data layer element of pageData.userConsent.   

When a user has not provided consent, the data layer variable UDO.pageData.userConsent will have a value of “no”.  When a user has provided consent, the data layer variable UDO.pageData.userConsent will have a value of “yes”.

• a button that changes the value of the user consent when clicked.  This button also fires a s.tl() call.

Code update-

In the page code, I need to add logic to check the user consent, and appropriately set the [cm.ssf] context variable.   For reporting purposes, I’m also setting a prop (s.prop5) to indicate if the data is being passed to AAM or not. 

Below is the code snippet that is added on both test pages.

If user consent is “no”, the [cm.ssf] context variable should be set to “1”.  Prop5 is set with the value of “Do NOT send to AAM via SSF”. 

If user consent is “yes”, the [sm.ssf] context variable should be set to “0”.  Prop5 is set with the value of “sending to AAM via SSF”. 

Now that I’ve implemented the necessary changes, I can go to the browser to validate everything is working as expected.

Validating in the browser

The tools I will use for validation include:

• Browser Developer Tools (I am using Chrome, but any browser will work)

On my sample webpage, where SSF has been configured (also the default behavior) and in this case the cm.ssf context variable has been set to “0”, the Analytics hit response shows a postback response with information. This indicates data is being server side forwarded to AAM and AAM is able to pass back information. 

In the Analytics hit, you can see the [cm.ssf=0] context data variable get set.

For demo purposes, I do NOT want to share Analytics data with AAM on page2.  The [cm.ssf] context variable value needs to be set to “1”.  

Once I navigate to page2, where consent has NOT been provided, the Analytics hit response shows a postback response without information. A “status:SUCCESS” indicates server side forwarding is enabled for the report suite, however, data is NOT being forwarded to AAM.  Also note, AAM pixels do not fire (ie.  dest5.html pixel or URL destination pixels).

In the Analytics hit, you can see the [cm.ssf=1] context data variable get set.

Validating in Analytics

In Analytics, real-time reporting can be leveraged to confirm your implementation is working as expected.  The data is reported in less than two minutes and auto-updates on a minute-by-minute basis.   Refer to https://docs.adobe.com/content/help/en/analytics/components/real-time-reporting/t-realtime-admin.htm... for detailed steps on configuring real-time reports.

For validating SSF, I’ve configured my report as shown below. 

The Instances metric will provide a count of how often the cm.ssf variable values are set.  My secondary dimensions are AAM test (s.prop5) and Page (s.pageName).

Validating in AAM

Keep in mind the reporting in AAM has a last day lookback, so you will not be able to validate in real-time. 

Using the prop that I implemented, I configured 2 AAM traits – “CM.SSF Flag – sent” and “CM.SSF Flag – don’t send”, as shown respectively below.   

In the General Reports (Analytics > General Reports), I can view the Unique Trait Realizations of both traits by selecting the two traits and running a report.

Since the prop will only be set to “do not send to aam via ssf” when the [cm.ssf] context variable is set to “1” (meaning SSF should not occur), the “CM.SSF Flag – don’t send” trait should never be realized or have any population. 

AAM reports on unique devices or users, so as expected there is 1 unique trait realization based on my testing.

Considerations

While, this solution will control the analytics data that is forwarded to AAM, it does not control Adobe Analytics segments that are shared to the Marketing cloud and leveraged in AAM.  It is imperative that customers consider the composition of segments to ensure their data governance requirements are met.

The [cm.ssf] context variable can be used alone to control the data sent from Adobe Analytics to AAM via server-side forwarding, as discussed in this article.  This solution can also be combined with other offerings (ie.  Opt-in service, Visitor Service configurations, GDPR API) to provide Adobe customers additional levels of control and governance. 

[#2]

@anhousto1 ,

I have a scenario in which if user says no to marketing cookies for the first time or later sometimes the server-side forwarding to AAM looks disabled in page view calls (s.t calls) but it's not actually disabled in event/custom calls (s.tl calls). This will leak the data to AAM and violates GDPR guidelines.

For s.tl() calls we have to implement contextData.cm.ssf variable so that no data is forwarded to AAM. 

Implementation is done via Launch. 

Why does the optout work for s.t() calls but not for s.tl() calls?

[#3]

@vibhatna The context data variable should also get included in s.tl() calls. Be sure you are including "contextData.cm.ssf" in your s.linkTrackVars list prior to the s.tl() call.

[#4]

@anhousto1,

That is the question. Why do we have add  "contextData.cm.ssf" in s.linkTrackvars for s.tl() calls explicitly? Shouldn't the AAM optout work for both s.t and s.tl calls?

[#5]

@vibhatna - Yes, if it has already been set (or reset) in a previous call.  But if not and you need to set it within the s.tl() call (ie. when a button is click)- just like any other analytics variable- to include it in the s.tl() call you must include it in the s.linkTrackVars list.