Generally that is what happens with Launch already (without needing any rules since Launch for AA works a bit differently in mobile vs web). Essentially in your AA extension, you specify the report suites where you want the data to be sent and in processing rules, you would see the context data in your dropdowns. Take a look at this link for a more pictorial walkthrough (thanks to Jan Exner). https://webanalyticsfordevelopers.com/2020/03/03/adobe-experience-platform-mobile-sdks-mapping-data-for-...

That is an absolutely fair statement. Tools have costs and it's important to ensure we're getting the most value out of them. That being said, personally, before onboarding any product, I prefer to get a capabilities walkthrough (essentially the sales demo which demonstrates all the capabilities of the platform or feature). We can then assess our plan to see if we're actually leveraging all the features which matter to our business. That is also an important distinction as well, the AA platform ...

Great advice from @AlexisCazes and @thebenrobb ! To add to that: 1.) Create your own set of best practices, taking inputs from your site developers and QA folks to determine how reliable and performant a particular piece of code can be. Typically sites which have had marketing capabilities before the implementation of a tag manager, would need those implemented by a developer directly on the site code (then typically tested before releasing) - so your colleagues can be a great allies here. 2.) P...

Out of curiosity, did you add the necessary processing rules to map your contextData to AA variables?

Hi @JohnRog This could be done by engaging your solution consultant or MSA via your CSM at Adobe. You could also engage third party companies. The outputs of these assessments are typically in a report with some high-level headings. It would serve you best to identify the objectives of your audit - for instance, do you have a lot of custom code and would like a code review for efficiencies? Is it the first time around for your team and you're looking for a best practices recommendation from an A...

Depending on your company there are other values you could use. Domains, for instance - if all internal users are on a common domain (ie: mycompanydomain.com) that is a default dimension which is collected based on the user's internet connection.

Try the following: Clear browser cache/cookiesTry Private/Incognito modeShouldn't be a permissions issue, but good to check anyways

That is correct - hopefully you're not in the middle of writing an exam of some sort 🙂 https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/products.html?lang=en#examples

Hi @DebbyNPL - your logic is sound, but it is my understanding that by using the date range feature in the Segment Builder, you override the panel's default date range. Ben Gains posted a video introducing rolling dates in segments and how it superseded the date on the report's panel itself. It looks like the reverse may be true as well. Here's the video just for fun: https://experienceleague.adobe.com/docs/analytics-learn/tutorials/components/segmentation/rolling-date-ranges-in-segments.html?la...

Also, check your implementation for the "Site Section" dimension. Depending on how the larger site is structured, that may have what you need already. If not, +1 to @Andrey_Osadchuk and @mikeetiuPH 's approaches.

Yes, to be safe, only update the rows which you need to overwrite.

+1 to leveraging the API - it will give you a lot finer-grained control to your data pulls and it will break you away from Excel's performance limitations if you're consuming large amounts of data. One potential barrier would be if you're unfamiliar with APIs and programming for data pulls/processing. The second option, if you absolutely must use Excel is to use Power Query + the API above. It still requires the same level of programming though. Another method, mentioned by @WayneV is to structu...

Hi Daniel,To clarify, are you setting both page load rules to each fire a separate call to analytics?

A reasonable best practice for multilanguage sites is to utilize a language variable (preferably in a data layer) and provide all the reporting in a single language (ideally localized to your report consumers). You would want to avoid having pages named differently to align with the language. Since you're also using a CMS, partnering with your developers is key in getting the data exposed consistently.There are a few ways to do this, but let me cover the top 2 . (using the contact us example fro...