Adobe Experience Platform

Pushing multiple data simultaneously into Adobe Client Data Layer can cause its computed state to return data that you don't expect. Overcome this problem in Tags (Launch) with Direct Calls. Preface / Background Adobe Client Data Layer, commonly referred to by its abbreviation "ACDL", is an event-driven data layer developed by Adobe. This article assumes that you are already familiar with ACDL and know how it works, or even how to use it. Otherwise, learn more about ACDL from its wiki. Like any event-driven data layer, ACDL's implementation is very simple: instantiate its array, then push a data object into that array, like so: // instantiate ACDL window.adobeDataLayer = window.adobeDataLayer || []; // push data into ACDL window.adobeDataLayer.push({ event: "my event", foo: "bar" }); After that, you can retrieve the pushed data from ACDL's computed data layer state. When using Tags (or Launch, as it is more commonly known), then you can use the Adobe Client Data Layer extension's

November 2022     This is a roadmap.  It is not a promise.  It is a snapshot of what we think we can deliver based on our priorities at this current moment .  You should expect things to move around.  New items will be added.  Individual items will move closer and farther when development teams refine scope, update priorities, or otherwise learn that things did not take the exact amount of time that we estimated.  We reserve the right to be smarter tomorrow than we are today. Most recent update: 2022-11-15

If you're using Adobe Client Data Layer (ACDL) in Tags (Launch) and ordering of Rules is important to your setup, then setup your ACDL Events to listen to "All Events" only. Preface / Legend For the rest of this post, I'm going to use specific upper- and lowercase spellings to distinguish various items. Uppercase "Event", "Condition", "Action": these refer to the Events, Conditions and Actions in Tags that come from extensions. For example, the ACDL extension has an Event called "Data Pushed". Uppercase "Rule": this refers to Rules that are setup in Tags. A Rule can contain 1 or more Events (where each Event doesn't have to come from the same extension), 1 or more Conditions, and 1 or more Actions. Lowercase "event": any other event that occurs during your web page's runtime, i.e. when it is loaded and interacted with in the user's browser. "ACDL event": an event that got pushed into ACDL / adobeDataLayer. Background Tags, or Launch as is more commonly known, has a fantasti

Community Members,This post will serve as a collection point for the various blogs and articles around Launch, by Adobe. As your community manager, I will do my best to keep this list updated and organized. If you have suggestions for this page, please let me know.Official Blog:https://medium.com/launch-by-adobe/adobe-web-browser-technology-performance-477c2bfeaa98https://medium.com/launch-by-adobe/none-data-element-storage-duration-a16433791048https://medium.com/launch-by-adobe/data-persistence-from-dtm-to-launch-52d26b834b54https://medium.com/launch-by-adobe/event-detection-from-dtm-to-launch-b4370cc21bb8https://medium.com/launch-by-adobe/launch-library-monitoring-hooks-8495dd91b57https://medium.com/launch-by-adobe/custom-code-event-type-9953b6f3d664https://medium.com/launch-by-adobe/client-side-help-for-gdpr-79e1cbcfc3c2https://medium.com/launch-by-adobe/migrating-from-dtm-to-launch-57548251a86dThird Party Blogs: http://www.stratigent.com/community/analytics-insights-blog/preparing-

This change was released on July 7th, 2020.--We've made a significant update to the Launch browser runtime to add a new capability. This article will clearly describe the legacy behavior, the new behavior, and some things you should consider as you make the move.  Let's dive in!1) Legacy behaviorWhen a rule contains multiple actions, Launch will call those actions in the same order that you have them organized in the interface.  In this example, Launch will call Action A, then Action B, then Action C.What Launch does not do is wait for Action A to finish before it calls Action B. If Action A is synchronous, then it doesn't matter much. But if Action A is asynchronous, then Action B probably starts to run while Action A is asynchronously carrying out its task. Over the long-term, we'd expect to see that sometimes Action A finishes before Action B, but sometimes it finishes afterward. The same is true for Action B

MobileSDK – CDP: Data Refresh StrategyAuthors: Meera Ankam, Raminder Singh Bagga IntroductionIn mobile app development, ensuring data accuracy and completeness is crucial. Mobile SDKs capture user interactions and other relevant data, but transmission failures can lead to incomplete or lost batches due to network issues, server downtime, or SDK bugs. Reingestion mechanisms retransmit failed data batches to prevent data loss.This blog presents strategies and best practices for reingestion to effectively manage and mitigate the impact of failed batches from Mobile SDKs to the Edge Network and into the Adobe Experience Platform (AEP) Dataset.Real World Customer ExampleBackgroundWe're diving into a strategy guide on re-ingesting failed batches using Adobe Mobile Edge SDK for data collection. Many of our customers rely on this SDK to construct XDM (Experience Data Model) on the client side, ensuring consistent data structure and interoperability across Adobe Experience Cloud solut

(Disclaimer: The following recommendation is based on my personal experience with actual client setups. It is not endorsed nor recommended by Adobe or any of its partners.)I'm sharing this scaffold for using Adobe Web SDK to send events for Adobe Analytics to consume, with Adobe Client Data Layer (ACDL) as the data layer and Adobe Experience Platform Tags (a.k.a. Adobe Launch) as the tag management system.The full gist is at https://gist.github.com/yuhui/0cb20fdcc21a03357c4a217edc58d63a. I've listed out the minimal set of:extensionsdata elementsrulesthat need to be set up in Adobe Launch to enable complete tracking of your website's usage data to Adobe Analytics via Web SDK + ACDL, i.e. your website with Adobe Launch -> ACDL -> Web SDK -> Analytics.Hopefully, this scaffold is useful for those of you who are getting started with implementing Web SDK for Analytics, or migrating from Analytics' AppMeasurement to Web SDK.If you find any errors or have any comments, please fee

We would love your feedback on the attached documentation in the next 1-2 months while we are awaiting the final feature. Please reply to this thread and let us know what you like and what improvements can be made. Thanks!

When configuring a click event in Adobe Experience Platform Launch, there is a setting that is commonly referred to as “link delay”. This is a complex piece of functionality that is not well understood. Today I want to demystify this capability. I will explain what it is doing, potential issues that you’ll face, and some workarounds for those scenarios. What it does The first thing of note is the element definition. Link delay will only trigger at runtime if your defined selector is a link element (an <a> tag). It will do nothing for any other types of elements. The next thing to know is what happens at runtime when you turn this on the link delay. When a click event is triggered on a link element that matches your selector definition, the Platform Launch runtime will: Call the event.preventDefault(); function - this has the impact of preventing the browser

On the Launch team, we consider openness and transparency to be items of high value. One of the requests we’ve heard from many customers is that you don’t really know what you’re getting when you install a new extension from the catalog. This is of less concern for mobile extensions since the source code is available through package managers and part of the compiled apps. But in a browser, it’s much more dynamic and harder to know what you’re getting.  JavaScript can dynamically inject more JavaScript and do many other things. Many of our users in industries with heightened security and privacy concerns have strict requirements around the code that is allowed on their sites. For users in this situation, extensions provided by 3rd parties can be a risk vector that must be accounted for. Some use

When Launch was still in the planning phases and we were first figuring out how extensions would work, we realized that Launch users were going to want to have private extensions.  Private extensions can be installed and used on a property like any other extension, but they are only available within the company that owns the extension.  Nobody else can see it.In order to deliver this feature, we need to make a few tweaks to the way that Extension Developers test their extensions prior to release.  These changes will put you as developers in full control of the lifecycle of your Launch extension.If you are (or want to be) a Launch extension developer, please keep reading for some important info. Also, please come join fellow extension developers and members of the Launch engineering team in the Launch Developers Slack workspace (click here to join).If you're a Launch user who is anxious to use Private extensions, stay tuned for updates, the Release Notes will probably you

This feature would recognize valid functions/syntax for calculated fields when entered as text input in the mapping interface and treat them as the calculated field data type. Currently, Datastream mapping does not allow you to input calculated field functions as regular text input in a source field. The function does not work and the data is not passed into the target field when doing so. Instead, you must enter the calculated field through its own UI. This means that you cannot update an existing source field to use a simple function like lower(), for example. Rather, you must delete the existing mapping and recreate it through the calculated field UI. Even after creating a calculated field through the UI, you cannot paste that same field in other source fields. This means, in order to use the same calculated field for multiple mappings, you must recreate the calculated field every time. Creating this feature would improve mapping efficiency and prevent mistakes.

Effective monitoring in Adobe Experience Platform involves closely tracking various metrics and aspects of your platform's performance to ensure it operates smoothly and meets your business goals.Here are some key components of effective monitoring in Adobe Experience Platform:1. **Data Quality Monitoring:** Continuously monitor the quality of the data flowing into the platform. Identify and rectify issues such as duplicate records, missing data, or data inconsistencies.2. **Performance Monitoring:** Keep an eye on the platform's performance metrics, such as response times, data processing rates, and server resource utilization. Ensure that the platform is meeting performance expectations.3. **Usage and User Monitoring:** Track user activity within the platform. Understand how users are interacting with the system, which features they use the most, and if there are any bottlenecks or issues in their workflows.4. **Error and Log Monitoring:** Set up logging and error tracking to catch a

Technical Advisory: To All DTM/Launch Customers Serving Libraries inside Mainland China Notification of Service ChangeEarlier this year, there was a degradation in the performance of our service in Mainland China affecting the domain adobedtm.com. To address the performance issues and comply with new regulations, Adobe has created an entirely new domain (adoberesources.cn). The Adobe Launch product and engineering teams are working on providing new environment embed codes using this domain within the product for those customers wishing to host inside mainland China and still leverage an Adobe Hosted option.  DTM will not be retrofitted with this capability so migration to Launch will be a prerequisite.   Customer ImpactCustomers who use the  “Managed By Adobe” host in Launch, or the Akamai embed option in DTM, have their libraries hosted on the adobedtm.com domain. This do

If you use Web SDK for tracking purposes, you'll find that it is very difficult to read the event data in the AEP Debugger browser extension. This is because, by default, the Debugger does not parse JSON strings. As a result, all of the Web SDK event data gets lumped up in one loooooooooong single string, making it difficult to validate the individual field values properly. Even worse, because of this deficiency, the Excel download that the Debugger provides also suffers from very looooooooong JSON strings. And given how Excel formats cell sizes, the resulting spreadsheet can be very unwieldly to use! Contrast this with the Excel download that the Debugger provides for Analytics hits. Now, that download is much easier to open in Excel, and the individual data points, e.g. props, eVars, events, can be inspected more efficiently. (Side note: I've already added an Idea to parse the JSON output for Excel downloads in the debugger. Please upvote/like it if you want to see this Deb

On September 1, 2020, we tweaked the way that data element default values are set. Newly created data elements will no longer have a default value set automatically. Today I want to explain what the default values are for, why we're making the change, and explain the specifics of the change.Data Element Default Value UsageFor the purposes of this conversation, we'll define "data element" to be a pointer to data that will exist inside the client environment at run-time.  "Data element value" or simply "value" refers to the actual value that the data element points to or "resolves" to at run-time.Data elements can be used within events, conditions, actions, extension configurations, and even other data elements.  At runtime, the data element is resolved at the time that it is needed.  For example, you have a rule with a data element reference inside an action.  The rule's event is triggered, the conditions are evaluated, and so now we have to run the action.&nbsp

The BackgroundIn the old days of Adobe tag management, DTM provided a Google Analytics tool to help with the deployment of Google Analytics tags.With the initial development of (at the time) Launch, by Adobe, the Launch team built an extension for Google Universal Analytics to maintain feature parity for Google tags and to provide a known upgrade path for DTM customers.We eventually developed a Google gtag extension and a Google Ads extension to aid in deploying those technologies as well.  We had good intentions with the release of these extensions, but it was hard to prioritize any product work on these extensions when we had so much that we wanted to do with our own technologies. We didn’t even get around to updating the Google Analytics extension to use our own Gtag extension. The availability of Google Analytics 4 forced a reckoning where we needed to make some long-term decisions about the future of these extensions.The Google Global Site Tag extensionIn the interim, Ac

There is a new Chrome extension for local browser embed code changes is live. This is not an official Adobe product. You can get it here - Launch Command - Chrome Web StoreDirect Link (Copy/Paste)https://chrome.google.com/webstore/detail/launch-command/nkjhamgjeocefocmpbcjfmohkjgildkiOnce it's installed, you can right click on it and select "Options" to view the help docs if you have questions.

What is Changing?Adobe Experience Platform Launch is updating our underlying infrastructure and deployment pipelines.  This requires us to use new egress IPs.The new egress IP addresses are:184.72.239.6823.20.85.11354.226.193.184ImpactIf you are adding Launch egress IPs to an allow list for any reason, you'll need to update your allow list.The most common reason for adding Launch IP addresses to an allow list is when you're using an SFTP host to receive your Launch library builds.If you are not able to quickly update your allow list, and you need to do a deploy in between now and then, one potential workaround is to switch to an Archive build on the Managed by Adobe host, then download that .zip file.When Will This Happen?This change will go into effect on Tuesday, October 27th.

If you’ve ever seen the inside of the Admin Console for Launch Client Side or Launch Server Side, you’ve probably seen the Manage Properties right under the Company Rights tab.Any users who belong to a group with this Permission Item can create new properties, edit the settings on existing properties, and delete properties. However, there’s another tab where you can select from a list of all existing properties and limit the group’s access to a specific subset of properties. The interaction between these two sets of rights creates a strange scenario, where any time you had a group with the Company Rights > Manage Properties right and Properties > Auto-include: Off, those users can create new properties, but cannot see them. That’s weird. We’re fixing this, but it requires a tweak to what the Company Rights > Manage Propertie

Update: The DTM Sunset Milestone dates outlined below have all been shifted back 1–2 weeks to accommodate release cycles and company events. Individual dates may be shifted again as they approach, but we promise they won’t be sooner than what’s below.--March 2020 Update: We’ve heard from a number of customers that the COVID-19 situation is disrupting the priority of their tagging projects, resources, and timelines. To aid with this situation, the target dates for Milestone 2 and 3 below have both been pushed out by 3 months. We’ll continue to listen to feedback from customers and may further extend the dates.--July 2020 Update: We continue to hear from customers who are concerned about the impact that the COVID-19 pandemic is having on their migration timelines. We have resource, maintenance, and cost constraints that make it infeasible to push back Milestone 3 (the final EOL), but we have decided to shrink the read-only period from 6 months down to 2 months. This means that while

March 2020 Update: Due to the situation with SARS-CoV-2 and COVID-19, we have pushed out the dates for Milestone 2 and 3 by 3 months each.  The dates below have been updated to reflect these new dates.  We will continue to monitor the situation and may make further adjustments depending on how the next few months go.--July 2020 Update: We continue to hear from customers who are concerned about the impact that the COVID-19 pandemic is having on their migration timelines. We have resource, maintenance, and cost constraints that make it infeasible to push back Milestone 3 (the final EOL), but we have decided to shrink the read-only period from 6 months down to 2 months. This means that while the final EOL timeline is not changing — it is still April of 2021 — you’ll be able to continue to make changes to your DTM properties until February of 2021. The official dates below reflect the latest changes.--February 2021 Update: We’ve pushed out the Milestone 2 date by 6 days to align

A Brief History of Tag Management at Adobe Adobe’s foray into the tag management space began in earnest in 2013 with the acquisition of Satellite and its adoption into the DX family of products. Yes, technically, Adobe Tag Manager came first, but that’s where the “in earnest” comment comes in.Satellite was renamed to Dynamic Tag Management (DTM) and grew from tens of customers to hundreds in a short amount of time. This rapid growth exposed several issues that we needed to address: DTM worked well for deploying Adobe technologies (and one Google one), but if you wanted to deploy anything other than that, you had to use custom JavaScript and HTML. SPAs were becoming more popular and the common “Page Load” paradigm for triggering Tag Management events became inadequate for meeting everyone’s needs. The Apple and Google app ecosystems continued to grow, and the tag managers of the

This tip is for extension developers (most likely applicable for web extensions only, since I haven't tried this with mobile extensions).TL;DR create a "global.turbine" variable to mock the turbine free variable, before running your unit tests.I use jasmine (https://jasmine.github.io/index.html) for testing my extension. One difficulty that I had was figuring out how to test the "turbine" free variable (https://experienceleague.adobe.com/docs/launch/using/extension-dev/turbine.html).After numerous trials-and-errors, I finally stumbled on this solution:describe("description of the test suite", function() { // create the turbine free variable with "logger" global.turbine = { logger: jasmine.createSpyObj('', ['debug', 'info', 'warn', 'alert', 'error']), }; // rest of test suite it("description of unit test that logs to the logger", function() { // run the test expect(global.turbine.logger.info).toHaveBeenCalled(); }); });Hope this works for you too!

Update: Roadmap Updates are now posted at Data Collection Roadmap!As the Adobe Experience Platform has evolved, so has the Launch team and our place within the Platform.  Our portfolio has expanded beyond web and mobile - and now includes Launch Server Side, the Edge Network, the Web and Mobile SDKs, and a bunch of other exciting things.  Our team has welcomed new product managers and engineers.  Our managers have been given new teams to manage.  All with the goal of making it as easy as possible to gather data from client devices and send it wherever you need it to go - Adobe and otherwise.  To reflect this expansion of our scope, we have put together the Data Collection Roadmap to provide broader insight into the things we're working on.  Roadmap updates will be posted on the new page.  We'll leave this one here for the archives and bookmarks.--When the Launch product team receives a feature request, we need to weigh it against all the oth