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.
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.
Learning to speak the Edge language will make you feel much more comfortable with getting started.
Tip #5: Use an Event-Driven Data Layer
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!
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.