Tuesday's Tech Bytes - Best practices to follow while migrating Adobe Web/Mobile SDK (Part 02)

[#1]

Hello everyone! Welcome to our fourth thread on ‘Tuesday's Tech Bytes’. This thread focuses on 'Best Practices for Adobe Web/Mobile SDK Migration’ and is the second part associated with the topic. Please head over here to read the first part and get some context before delving into the thread below.

Without further ado, let's pick up where we left off last week.

Evaluating and optimizing your dataLayer

• Critical dataLayer assessment: Before proceeding with migration, it's crucial to conduct a comprehensive technical evaluation of your dataLayer. This ensures that your dataLayer is not only robust but also aligned with your migration goals, helping you avoid potential issues down the line.
• Consult Dev Team for static dataLayer: Engage your development team to assess the resilience and reliability of your existing static dataLayer. Their insights can provide valuable input into the decision-making process regarding its suitability for migration.
• Plan for Event-Driven DataLayer when necessary: While considering migration, it's wise to have a clear plan in place for transitioning to an event-driven dataLayer. This strategy should be activated only if it is deemed necessary, based on your specific business and technical requirements.
• Leverage existing investments: Many organizations have invested significantly in their static dataLayers, making it cost-effective and practical to leverage what has already been built. Utilizing these existing resources can streamline the migration process and save both time and resources.
• Exercise caution with SPAs: When dealing with Single Page Applications (SPAs), approach the migration process with extra caution. SPAs have unique technical characteristics and challenges, so it's essential to tailor your migration strategy to address these specifics effectively and minimize potential disruptions.

Grasping XDM & JSON proficiency

• The critical role of XDM design: The design of the Experience Data Model (XDM) is pivotal in data collection, impacting Adobe Experience Platform (AEP), Adobe Analytics (AA), Adobe Audience Manager (AAM), and Adobe Target (AT). A well-thought-out XDM design ensures effective data handling across these solutions.
• Incorporate standard field groups: XDM design should aim to include standard field groups whenever possible. These standard groups automatically map to various Adobe Analytics reports, streamlining the data analytics process.
• Developer proficiency in JSON and XDM usage: The development team should possess proficiency in working with JSON and leveraging the XDM, enabling them to effectively implement and manage data within Adobe's ecosystem.
• Advance knowledge of XDM data validation and formats: It's essential for the development team to be well-acquainted with XDM data validations and formats in advance. This knowledge ensures that data adheres to the correct structure and is validated as per the XDM standard during the implementation process.

Leveraging Adobe's latest tools and features

• Adobe's new debugger: Adobe's latest debugger is a robust tool for analyzing image requests, encompassing requests, edge transactions, Adobe Analytics (AA) payload, and Identity-related data, providing valuable insights into the functioning of your Adobe solutions.
• Adobe Client Data Layer Extension: The Adobe Client Data Layer Extension allows you to listen to events and transmit metadata, enabling a pure event-driven analytics approach, which enhances data tracking precision and responsiveness.
• XDM Mapper: The XDM Mapper tool simplifies data transmission in XDM (Experience Data Model) format by reducing the need for custom code. This streamlines the process of sending data in a structured and standardized format.
• Identity Data Elements: Implementing ID synchronization becomes more accessible with Identity Data Elements, which provides an efficient way to set customer IDs through methods like setCustomerID, contributing to a smoother data management process.
• Core methods for code reduction: Utilizing core methods such as 'New/Repeat' and 'Visit Number' minimizes the requirement for custom code, optimizing efficiency and reducing development complexity in your Adobe solutions.

Understanding Adobe Analytics Limitations

• Validate WebSDK Plugins: Ensure that WebSDK plugins undergo validation, and their outcomes align with those of Adobe Analytics plugins.
• Processing Rules for Custom Variable Mapping: Custom variables like eVars and props are being extensively mapped using processing rules to ensure their proper functioning and data capture.
• Utilizing eventType, Pageview, and Non-Pageview Calls: The use of eventType, Pageview, and Non-Pageview calls plays a significant role in capturing specific data events and interactions within your analytics setup.
• Automatic Variable Mapping limitations: Variables that are automatically mapped may not be available for customization within processing rules, potentially limiting your ability to tailor the data capture process further.
• Standard Field Groups and Documentation discrepancies: Discrepancies between standard field groups and documentation can pose challenges in data management and interpretation, highlighting the importance of alignment between the two for more effective analytics.

Understanding Adobe Audience Manager and Adobe Target Limitations

• No AAM Server-Side Forwarding: You can skip the process of sending data from your servers to Adobe Audience Manager (AAM). Manage audience-related data directly within AAM, eliminating the need for server-side forwarding.
• XDM-Compliant traits: Update traits to adhere to the Experience Data Model (XDM) standards. This means following consistent data structure and naming conventions while abandoning the use of "c_" and "d_" variables for more efficient and standardized data handling.
• Signals and Audience Analytics impact: Changes in Server-Side Forwarding (SSF) will affect data exploration and audience analysis tools like Data Explorer (Signals) and Audience Analytics. Expect potential limitations and the need for adjustments in these areas.
• Pixel implementation modification: Adapt your pixel implementations to incorporate NextRow's SmartProbe solution (Contact Us to know more). This involves changing how data is collected and transmitted, enhancing your data tracking capabilities.
• Transition to "sendEvent" from AT Mbox: Adobe Target (AT) mbox, used for personalized content delivery, is being replaced. Instead, data collection should shift to the "sendEvent" method. This ensures consistent and effective personalized content delivery in your digital environment.

Mastering Identity limitations

• ID Service transition: Adobe Experience Cloud ID Service is a legacy system, while the Adobe Experience Platform Identity Service is the new approach for managing user identities. Plan for the transition to the new service.
• 3rd-Party Cookie support in DSPs: It's important to note that several Demand-Side Platforms (DSPs) still rely on 3rd-party cookies for tracking and targeting. Ensure compatibility during your configuration for continued data sharing.
• AAM 3rd-Party ID sync: Don't overlook the migration of existing 3rd-party ID synchronization in Adobe Audience Manager (AAM). This includes transitioning container IDs to maintain data continuity.
• Cookie changes: Be aware of alterations in cookie usage, such as the discontinuation of AAM 1st-party cookies and data reduction in AMCV cookies. These changes impact data collection and personalization.
• ECID set in Edge: The ECID (Experience Cloud ID) is now set within the edge, and it's not visible in image requests. This means that user identification and tracking processes have shifted to the edge environment, impacting data handling and analytics.

With this, we are closing our thread on 'Best Practices for Adobe Web/Mobile SDK Migration’. See you all next week with a different theme.