ACDL (Adobe Client Data Layer) Events Approaches for Page Loads
There are two school of thoughts when it comes to designing data layer events for load of the pages and user interactions:
![]()
In either case, the concept of user interaction events remains same. The idea is to have specific event for each user interaction type, e.g., “registration-start”, “registration-complete”, “add-to-cart”, etc. And then you build rules to listen to these events and fire analytics tags.
The interesting part is designing the page load events. Depending on the approach you pick from above, would decide how your implementation is going to look like. Below is a quick overview of how your implementation would differ based on the approach you pick:
| Rules | Approach 1 | Approach 2 | |
| Approach 2. A | Approach 2. B | ||
| 1. PDP Page | event: ACDL event “page-load”
condition: if (page == “pdp”) action: set product vars |
event: ACDL event “pdp-load”
No Condition action 1: set product vars + global vars action 2: send beacon |
event: ACDL event “pdp-load”
No Condition action: set product vars |
| 2. Search Page | event: ACDL event “page-load”
condition: if (page == “search”) action: set Search vars |
event: ACDL event “search-page”
No Condition action 1: set search vars + global vars action 2: send beacon |
event: ACDL event “search-page”
No Condition action: set search vars |
| 3. All Pages | event: ACDL event “page-load”
No Condition action 1: set Global vars action 2: send beacon |
event: ACDL event “all-pages”
No Condition action 1: set gloabl vars action 2: send beacon |
event: ACDL event “all-pages” or “pdp-load” or “search-page”
No Condition action 1: set gloabl vars action 2: send beacon |
Pros and Cons of Each Approach
| Approaches | Pros | Cons |
| Approach 1 | ||
| Approach 2.A | ||
| Approach 2.B |
Approach 1 seems to be a clear winner because of its robustness and easier to maintain nature. Approach 1 is what Softcrylic recommends adopting regardless of your data collection methodology – appMeasurement or Web SDK.