Can we use Computed Attributes to surface Experience Event-derived values at Profile level for Activation in AEP?

Yes, Computed Attributes can be used to aggregate ExperienceEvent data into profile-level attributes and activate those attributes through Real-Time Customer Data Platform destinations.

However, there are important considerations around the lookback window, refresh frequency, XDM data modeling, and the Adobe Campaign Classic export process.

1. What Computed Attributes can support

Computed Attributes can aggregate data from Profile-enabled ExperienceEvent datasets using functions such as:

• COUNT: Number of qualifying purchase or product-view events.

• SUM: Total purchase amount.

• MIN or MAX: Earliest or latest timestamp, depending on the requirement.

• MOST_RECENT: Most recent value from a qualifying event, along with its timestamp.

• LIST: A list of recent values, subject to additional limitations.

For example:

• Number of purchases in the last three months.

• Total purchase value in the last four weeks.

• Most recent purchase date.

• Most recent product viewed, when the product value is modeled in a supported form.

Adobe specifically documents purchase counts over three months and the latest product viewed as Computed Attribute use cases. Computed Attributes overview

2. A three-month lookback is not an exact rolling 90-day window

A three-month Computed Attribute should not automatically be interpreted as the previous 90 × 24 hours.

Adobe supports lookback durations in hours, days, weeks, and months. The available duration values are:

• Hours: 1–24

• Days: 1–7

• Weeks: 1–4

• Months: 1–6

Adobe also states that weeks and months follow calendar boundaries and that the lookback rolls forward. Therefore, a three-month configuration is better understood as a rolling calendar-month calculation rather than an exact 90-day calculation. Computed Attributes API

For example, assuming fast refresh is enabled and the first successful evaluation occurs on August 29:

When September begins, the window rolls to the next set of calendar months. June drops out, and September becomes the current month in the three-month calculation. This means the number of elapsed days represented by the window can vary. Consequently, this should not be positioned as an exact rolling 90-day calculation.

The above monthly example applies the behavior Adobe explicitly documents for the two-week fast-refresh example. Adobe recommends validating the exact result in a sandbox using the Computed Attribute’s Last evaluated timestamp.

3. Fast refresh improves frequency, not precision

A three-month Computed Attribute normally has a monthly refresh frequency. Fast refresh can make the value refresh daily for longer lookback periods.

However, fast refresh does not convert a three-month calendar lookback into an exact rolling 90-day lookback. The window can expand during the current calendar month and then reset at the next calendar-month boundary.

Computed Attribute evaluation is also independent of the audience evaluation schedule and the destination export schedule. Even after the Computed Attribute evaluation completes, the updated value may require additional time to appear in the Profile and then be exported to the destination. A buffer of a few hours should be considered before relying on the value downstream. Computed Attributes FAQ

4. Event type versus product-array granularity

A Computed Attribute can usually count qualifying events based on an event type or another event-level condition.

For example:

• Count purchase events in the configured lookback period.

• Count product-view events in the configured lookback period.

• Sum the value of qualifying purchase events.

The result of counting product-view events depends on how the data is modeled. If one ExperienceEvent represents one product view, COUNT can represent the number of product views. If one ExperienceEvent contains an array with multiple products, COUNT counts qualifying ExperienceEvents, not individual products inside the array.

The more difficult use case is retrieving the identifier of the specific last product viewed when the identifier is nested inside an array of complex objects, such as:

productListItems[].SKU

The MOST_RECENT function can work with primitive values and arrays of primitive values. However, the Computed Attributes interface has restrictions around using array-type event attributes for filtering. Therefore:

• A flattened primitive field such as lastViewedProductId can be a good design for MOST_RECENT.

• A separate ExperienceEvent for each product view can simplify the calculation.

• A nested product array may prevent reliable filtering by a specific product identifier.

• Counting product-view events does not identify which product was viewed last.

This is why the exact XDM representation of the product data must be reviewed before confirming that “last product viewed” can be implemented.

5. Activation to Adobe Campaign Classic

Published Computed Attributes are created as profile attributes in the profile union schema under the system computed attribute field group. Adobe states that these attributes can be used for segmentation, personalization, and activation.

For the Adobe Campaign destination, the flow is profile-based and batch-oriented:

1. A segment is selected for activation.

2. The required identity is selected.

3. The Computed Attribute and other profile fields are selected as destination attributes.

4. Experience Platform exports the audience and selected fields to a CSV file in the configured storage location.

5. An Adobe Campaign Classic workflow imports the file and maps the fields into the appropriate Campaign profile or extension table.

Therefore, the answer is generally yes: a published Computed Attribute can be selected as a profile field for activation, provided it is visible in the union schema and available during the destination mapping step. This should still be validated in the customer’s sandbox because destination configuration, permissions, schema design, and field availability can affect what appears in the interface.

This is not a direct real-time transfer into Adobe Campaign Classic. It is a batch file exchange followed by an Adobe Campaign workflow. Adobe’s documentation specifically references Amazon S3 and Azure Blob Storage for this flow, so the organization should also verify that its Azure Data Lake Storage configuration uses a supported storage connection. Adobe Campaign destination

Recommendation

I would summarize the answer as follows:

Computed Attributes are suitable for exposing many ExperienceEvent-derived values at the profile level, such as purchase counts, purchase totals, and recent event values, and those published profile fields can generally be included in the Adobe Campaign Classic batch activation flow. However, a three-month Computed Attribute should not be treated as an exact rolling 90-day calculation. With fast refresh, it can be updated daily, but the calendar-month lookback can expand and reset at calendar boundaries. In addition, event-level aggregations are much easier when the required value is modeled as a primitive event field. Product identifiers nested inside arrays of complex objects can be difficult or unsupported for precise filtering and “last product viewed” calculations. If the business requires an exact rolling 90-day window or complex product-array logic, a scheduled query or upstream computation that writes a profile-ready attribute may be more appropriate.