Adobe eVars with "Expire Never" and the CJA Person Reporting Window

Background

In Adobe Analytics, configuring an eVar to "Never Expire" ensures that its assigned value persists indefinitely, maintaining continuity across multiple user sessions as long as the visitor identifier (cookie) remains intact.*

This setting is particularly beneficial for businesses with extended sales cycles, such as B2B enterprises or industries like real estate or insurance where the path from initial engagement to conversion can span months, or even years. 

The "Never Expire" option makes it possible for attribution models to use key dimension values throughout the entire visitor conversion window. 

*It is also worth acknowledging that changes in the privacy landscape and evolving browser policies that enforce shorter cookie expiration windows or block third-party cookies altogether, have chipped away at the value of setting the eVar expiration window to "Never Expire".

TL;DR

In Adobe's Customer Journey Analytics (CJA), the "Person Reporting Window" expiration setting can be a valuable asset when trying to account for conversion windows that span longer than 90 days. When using dimensions configured in this way, it's important to select the full date range you're trying to examine. This is a key difference when comparing the Person Reporting Window feature to the legacy "Never Expire" setting in Adobe Analytics.

Migrating to Adobe Customer Journey Analytics and Understanding Expiration Settings

The "Never Expire" setting for Adobe Analytics eVars is not available in CJA, which poses a challenge for organizations migrating to it. Again, this is especially true for those relying on long-term data persistence for extended sales cycles. In CJA, time-based expiration settings allow you to set a persistence window using the following units of time:

• Minutes
• Hours
• Days
• Weeks
• Months
• Quarters

with a maximum duration of 90 days (expressed in any of of the above units).

Additional expiration settings include: Session, Metric, and Person Reporting Window. Adobe provides this description for the Person Reporting Window setting: 

• Person: Expires at the end of the reporting window.

This description does not provide a lot of detail, so the goal of this blog post is to better understand how this setting works and illustrate its use through a couple of examples.

Use Cases

To better understand this expiration setting we'll use with three fictitious scenarios:

Scenario 1

A user lands on the website on a given day and within the same session (and tracking request) the user views an impression of a upsell offer and also completes a transaction for $50. We can summarize this activity using a simple table:

The data can be loaded in the test dataset using this JSON block containing both the impression and transaction amount (formatted to fit the schema specified in step 1 of setup section):

{
  "_id": "3",
  "eventMergeId": "",
  "eventType": "pageView",
  "identityMap": {
    "key": [
      {
        "authenticatedState": "ambiguous",
        "id": "sameHitTestCookie2",
        "primary": false
      }
    ]
  },
  "producedBy": "self",
  "timestamp": "2024-11-13T20:20:39+00:00",
  "upsells": {
    "upsellImpressions": [
      {
        "ID": "Upsell Promotion Same Hit as Conversion",
        "displays": 1,
        "selected": 0,
        "type": "Banner"
      }
    ],
    "upsellTransaction": {
      "transactionAmount": {
        "amount": 50,
        "conversionDate": "2024-11-13T20:20:39+00:00",
        "currencyCode": "USD"
      },
      "transactionDate": "2024-11-13T20:20:39+00:00",
      "transactionID": "Same hit impression and conversion",
      "transactionType": "Same hit impression and conversion"
    }
  }
}

Scenario 2

A user lands on the website on Nov 12 and sees a promotional impression. A day later (Nov 13) the same visitor completes a transaction for $20. This data is collected over two separate tracking requests/hits.

Here's a sample JSON payload used for the impression event on Nov 12:

{
  "_id": "10",
  "eventMergeId": "",
  "eventType": "pageView",
  "identityMap": {
    "key": [
      {
        "authenticatedState": "ambiguous",
        "id": "sameMonthTestCookie3",
        "primary": false
      }
    ]
  },
  "producedBy": "self",
  "timestamp": "2024-11-12T20:20:39+00:00",
  "upsells": {
    "upsellImpressions": [
      {
        "ID": "Upsell Promotion within the Same Month",
        "displays": 1,
        "selected": 0,
        "type": "Popup"
      }
    ]
  }
}

A JSON payload used for the transaction event on Nov 13:

{
  "_id": "11",
  "eventMergeId": "",
  "eventType": "pageView",
  "identityMap": {
    "key": [
      {
        "authenticatedState": "ambiguous",
        "id": "sameMonthTestCookie3",
        "primary": false
      }
    ]
  },
  "producedBy": "self",
  "timestamp": "2024-11-13T20:20:39+00:00",
  "upsells": {
    "upsellTransaction": {
      "transactionAmount": {
        "amount": 20,
        "conversionDate": "2024-11-13T20:20:39+00:00",
        "currencyCode": "USD"
      },
      "transactionDate": "2024-11-13T20:20:39+00:00",
      "transactionID": "Same Month Impression and Conversion",
      "transactionType": "Same Month Impression and Conversion"
    }
  }
}

Scenario 3

Our user lands on the website on Jan 12, 2024 and sees a promotional impression. On Nov 13 (305 days later) the same visitor completes a transaction for $10. This data is collected over two separate tracking requests/hits.

The JSON payload used for the impression event on Jan 12:

{
  "_id": "20",
  "eventMergeId": "",
  "eventType": "pageView",
  "identityMap": {
    "key": [
      {
        "authenticatedState": "ambiguous",
        "id": "90+daysTestCookie1",
        "primary": false
      }
    ]
  },
  "producedBy": "self",
  "timestamp": "2024-01-12T20:20:39+00:00",
  "upsells": {
    "upsellImpressions": [
      {
        "ID": "Upsell Promotion 90+ days",
        "displays": 1,
        "selected": 0,
        "type": "Popup"
      }
    ]
  }
}

The JSON block used for the transaction event on Nov 13:

{
  "_id": "21",
  "eventMergeId": "",
  "eventType": "pageView",
  "identityMap": {
    "key": [
      {
        "authenticatedState": "ambiguous",
        "id": "90+daysTestCookie1",
        "primary": false
      }
    ]
  },
  "producedBy": "self",
  "timestamp": "2024-11-12T20:20:39+00:00",
  "upsells": {
    "upsellTransaction": {
      "transactionAmount": {
        "amount": 10,
        "conversionDate": "2024-11-12T20:20:39+00:00",
        "currencyCode": "USD"
      },
      "transactionDate": "2024-11-12T20:20:39+00:00",
      "transactionID": "Conversion 90+ days after impression",
      "transactionType": "Conversion 90+ days after impression"
    }
  }
}

The goal of the exercise is to identify a way that would make it possible to accurately attribute the different transaction amounts across these three different scenarios to the most recent upsell impression the user viewed prior to completing a transaction. In Scenario 3, the time elapsed between the impression view event and the transaction complete event is more than 300 days, so the CJA time-based expiration settings which max out at 90 days will fall short.

The Setup

1. We will build a schema and dataset specifically for the purposes of testing using the built-in selection for an "Experience Event" schema and adding the out-of-the-box "Upsell Details" field group (Detailed instructions for building your own testing dataset)

We can obviously build a fully customized schema to better match specific requirements, but in this case an existing template gives us enough of flexibility to quickly complete the setup without spending extra time on a custom schema and database config. We should be able to load the data from the sample JSON payloads above. 

2. In our CJA data view, we'll create two copies of the ID (upsells.upsellImpressions.ID) dimension. 

3. We'll configure the first copy with the following settings and name it "Most Recent Promotion Viewed (30 days)":

The second copy we'll call ""Most Recent Promotion Viewed (Person Reporting Window)" and configure it to expire with "Person Reporting Window":

The Results

1. As expected, the default ID dimension (which has no allocation and expiration settings and is in effect a hit-based dimension for wherever the field upsells.upsellImpressions.ID is set), shows the $50 transaction that occurs on that same exact hit. Also as expected, the promotional impressions for the other two scenarios are not associated with any transaction amounts:

2. Looking at the 30 day expiration panel, we can see that this dimension indeed stops attribution at 30 days—Scenario 3 with promotion value of "Upsell Promotion 90+days" is not associated with any dollar value. We can also see that the $10 generated by this visitor are being attributed to the "No Value" line item.

3. The Person Reporting Window panel, as long as the date selection goes back to Jan 1, 2024, is able to to show us the expected attribution even in cases where the conversion window is 90+ days. Eureka!

The documentation from Adobe  states that the Person Reporting Window looks at all visits back up to the first of the month of the current date range. In our example, changing the start date to Jan 30 (even though the first activity was generated on Jan 12) still allows us to attribute the conversion event: 

In a panel where the calendar selection is limited to Nov 1-28, 2024, the impression that occurred back in January is no longer getting credit:

Conclusion

The CJA Person Reporting Window setting can be a valuable asset when trying to account for conversion windows that span longer than 90 days. When using dimensions configured in this fashion, it is important to select the full date range that you are trying to examine and this is a key difference when comparing this capability to the legacy "Never Expire" eVar setting in Adobe Analytics.