10 Tips to Get Started with Edge Data Collection

[#1]

Introduction

By now you have probably heard of the Web SDK (Alloy.js) and Edge Data Collection. Whether you are on a quest to learn more about Adobe's new technology or aren't sure where to start with your migration, we're here to help you. In this blog, we're diving into the world of Web SDK and Edge Data Collection to demystify the process, share our best tips and tricks, and equip you with the know-how to kick start your migration journey.  

Tip #1: Pick the Right Moment 

Identify specific use cases where Edge Data Collection would make a difference. Some common use cases include real-time segmentation and personalization, real-time triggers via Adobe Journey Optimizer, solving for cookie deletion, establishing a semantic data structure, offloading third-party tags, and reducing page JavaScript. Additionally, you may be looking to modernize your outdated implementation with Adobe's latest data collection technology.

Once you've identified your use cases, it's time to start planning for migration. 

Tip #2: Take Out the Garbage First 

Implementations have a tendency to get messy over time, and sometimes out of date. Before migrating to Edge Data Collection, take the opportunity to audit your existing implementation and refresh your Business Requirements Document and Solution Design Reference. This is the perfect time to remove extra code and focus on what is important to your implementation.  

Tip #3: Check Your Assumptions 

Remember that Edge Data Collection is an evolving technology. New capabilities are still being released, some features are not yet supported, and other functionalities will not be supported such as hierarchy variables, AMP (Accelerate Mobile Pages) pages, and some redirect pages. Before beginning your migration, get to know the features of Web SDK and Edge Data Collection and understand the nuances in feature parity compared to legacy implementation methods. Be sure to check the Web SDK Roadmap Status for updates on feature status and releases.  

Tip #4: Understand the Language 

Edge Data Collection comes with a whole new set of terms, so take the time to learn the language. Familiarize yourself with the key terms including Platform Edge Network, Web SDK, Mobile SDK, Server-Side API, and XDM. In addition to how the data is collected, Edge Data Collection relies on schemas, which come with their own terminology: schemas, field groups, fields, and data types. 

Learning to speak the Edge language will make you feel much more comfortable with getting started. 

Tip #5: Use an Event-Driven Data Layer 

An event-driven data layer is not a requirement for Web SDK, but we recommend using one for seamless data collection. In addition to reducing race conditions or timing issues when compared to a customer experience digital data layer, the event-driven data layer provides far more flexibility in your implementation. This approach allows your development teams to push events and data into a JavaScript array, aligning with the XDM data model and simplifying the integration with Edge. Using the Adobe Client Data Layer tags extension, that event data can be read and used to send data to the Edge. 

Tip #6: Learn Your Mapping Choices  

Remember that data needs to be in a specific structure for Edge and Adobe Experience Platform as defined by your XDM schema so it is important to think about how you will map your data to the XDM format. You may choose to use an XDM compliant data layer, map your data in tags (Launch), map your data server-side in Data Prep for Data Collection, or some combination of these options.  

Tip #7: Don't Leave Your Mobile Implementation Behind 

If you are thinking about migrating to Edge Data Collection, don’t forget about your mobile app. You can send mobile data to Edge by either updating to the Mobile SDK or leveraging the Bridge extension for iOS and Android until you can update your Mobile SDK. It is also worth noting that your Mobile SDK implementation can share a schema with your Web SDK implementation and in some cases, you can use the same datastream depending on the services you want to enable. 

Tip #8: Solve for Cookie Deletion with Device ID 

Adobe device identifiers, critical to unique visitor counts and visitor stitching, have traditionally been stored using cookies. But with growing browser restrictions around cookies, this has become increasingly unreliable, even affecting customers using a CNAME to generate a first-party cookie set by the Adobe server. Adobe's first-party device ID capability solves this by using a first-party cookie set by the parent domain to provide a seed value to manufacture or re-manufacture a consistent device identifier.  

Tip #9: Migrate Everything 

It can be tricky to mix and match legacy solutions and Web SDK because some combinations are supported, and others are not. For a smooth migration, we recommend starting with configuring Adobe Analytics in dev and testing before publishing to production, with data going to a separate report suite than your AppMeasurement implementation. Once you've validated between the two report suites, configure Web SDK and Edge for your other Adobe solutions in dev and validate, at which point you can remove your AppMeasurement.js and AT.js libraries from your development site. Once everything has been validated, push to production and continue to validate your solutions post-production.  

Tip #10: Steal Our Debug List 

As with any implementation you are likely to run into bugs throughout your migration. Do try to reuse existing Analytics rule logic, configure tag sequencing at the tags property level, use the same CNAME, migrate features like Data Insertion API and mobile data, and use Workspace for validation. Don't forget to carry over changes from one implementation to the other, distinguish your link page views and link clicks using the Analytics variable mapping guide, and keep in mind that Target data will go to Analytics. These tips will be especially helpful if you notice discrepancies in your AppMeasurement and Web SDK data.  

Bonus Tip: Let the AEP Debugger & AEP Assurance Help 

Use the AEP debugger to test and troubleshoot your Edge data. The AEP Debugger allows you to not only insert and replace embedded codes, but also view Edge logs and mappings to validate server-side configurations set though Data Prep, processing rules, and VISTA rules. The AEP Debugger also now works with Assurance, which allows you to view events and mappings, use the validation editor to create validation scripts, and view context data. These features will be extremely helpful for validating your implementation!  

Conclusion 

With these tips and learnings, you should have a solid foundation to get started with Edge Data Collection. Take the time to audit your existing implementation and thoroughly plan out your migration. Apply these tips in your own migration to take advantage of all that Edge and Web SDK has to offer.  

Relevant Links 

Data collection end-to-end overview 

Adobe Experience Platform Web SDK overview 

Adobe Consulting Services 

Contact Us 

[#2]

The links to definitions and guides was helpful

[#3]

What are the implications to Analytics here? Do I need to change my implementation or processing rules to account for this?

"and keep in mind that Target data will go to Analytics." 

[#4]

Thanks for this as I'm looking to embark on a websdk migration.

Some questions:

• Could you share some common issues encountered during migration and your recommended approaches for troubleshooting them?
• For companies with significant mobile app traffic, how should they prioritize and approach the integration of their mobile implementation with Edge Data Collection? How has it been and what are some key things to potentially watch for?

Thanks!