[AA Community Q&A Coffee Break] 04/05/23, 10am PT: Come ask questions on analytics, best practices, and tips & tricks with Ben Gaines, Director of Product Management for Adobe Analytics

Hi David. Yes, there absolutely is a way to do this using the API, and in fact if you don't mind setting up some API calls it is a much faster and more scalable way to get classifications data both into and out of Adobe Analytics. There are still limits to the export via API (I believe it is actually lower—25,000 rows?—though not 100% sure), but the advantage is that you can easily "paginate" through multiple API calls, so you can get rows 1-25,000 with your first call, 25,001-50,000 with your second call, and so on and so forth. 

Regarding your question on maximum size: you're right up to a point that keys that haven't actually appeared in your data are fine. I think we generally want to stay below 500,000 rows for a classification table; it is possible to go well beyond that, but there can be some performance degradation at that point. I'm checking with a colleague on that 500,000 number and will confirm. 

Hi Gurpreet. To be totally honest with you, it has been probably 10 years since I did implementation work and I have never worked with Xamarin. I don't know how well we can support Xamarin in terms of answering specific questions about it—I'm not sure we have Xamarin expertise on the team, since they are a third party—but I'm hoping another member of the community might have experience with it. If anyone out there has implemented Adobe Analytics using Xamarin, please weigh in to help Gurpreet! (Also, you might have better luck submitting this as its own forum thread, so it isn't buried on this massive page of content.) 

• I believe that CJA would be a perfect solution for this, but widespread implementation of CJA at this org might be a year+ away 

You're right—this is a great use case for CJA. But I understand that it's going to take some time to get there. 

• Are there any other workable ways to use internal customer IDs in the interim?
  • Using a Distinct Count calc metric on the customer-ID evar has a cardinality problem - comparing its results to a Data Warehouse export for a small subset of users (5% of total) is only 50% accurate

This was going to be my first suggestion, but you're right that it is estimated distinct count. The estimates do degrade with high-cardinality dimensions.  

• Someone suggested using Audience Manager to stitch user IDs together, much as you might do to unify a user across different devices. They weren't sure if cardiality would be an issue.

This is an interesting idea—what I'm not sure of is how you would feed those IDs back into Adobe Analytics. Would this essentially be a classification of device IDs into customer IDs? Would have to know more about the data to guess whether cardinality would be an issue. 

• I vaguely remember Customer Attributes when it was released - am I correct in remembering this would still count Uniques based on the Adobe ID, not any customer ID that is included with the upload?

That's correct, unfortunately—Customer Attributes describes the customer ID but it does not change how the IDs get counted as UVs. 

• Are there any other ways to consider? 

Do you know whether you are using Adobe Analytics Ultimate and, if so, have you considered Cross-Device Analytics as a way of having a bit more control over this? That's where I think I would start. Unless I'm missing something, Analytics Ultimate should let you stitch profiles together on a field (like an eVar). Doing it "at the source" (on the page/app) wouldn't work because you wouldn't have the ability to stitch anonymous traffic to known traffic post-login. Those are the only ideas I've got at the moment. 

Encode a campaign tag in them!

Great question. The answer (as always) is: it depends! We've actually got a decision tree to help you figure out the best approach. Most CJA customers send the data they're already collecting in Adobe Analytics over to AEP. We make that really easy, and we give you tools so you can do some data transformations along the way, including (importantly) aligning dimensions and metrics across report suites so they land in the same bucket in CJA. (So if you have multiple report suites with differing implementations, you can get a true global view in CJA without touching code on your pages/apps.) From there, it's just a matter of telling CJA which datasets you want to bring in, and then configuring how you want to view them in what we call Data Views (which are sort of like Virtual Report Suites for CJA, only with a LOT more control over the data—attribution settings, creating new dimensions out existing ones—that sort of thing).

I won't say it's a totally painless process. You do have to configure a lot of things, both in AEP (XDM, etc.) and in CJA (Connections, Data Views). But at least you don't have to go through the hassle of re-tagging. 

Now, some customers do choose to re-tag, typically using the AEP SDKs (web & mobile), which have a bunch of advantages and a few disadvantages. The advantages are one Adobe tag to rule them all, and an easier integration with Adobe's Real-Time CDP. The disadvantages are that there are a few remaining fields that the AEP SDKs don't capture, such as some of the Device and Technology dimensions—but we're rapidly adding support for those. 

If you choose to use the AEP SDKs, your implementation journey is similar once you've got data flowing in to AEP. 

The next big big BIG step is bringing in other sources of data—CRM, call center, email, point-of-sale, whatever—and in many cases AEP makes that easy with pre-built connectors. In other cases, you'd need to ETL that data into AEP yourself and map it to XDM before bringing it into CJA and merging it with your digital data (which we do make easy—just tell us which field is the customer ID and which field is the timestamp, and we do the rest to re-key and re-sequence all of your data for you). And then you can do amazing things like see the impact of a point-of-sale marketing campaign on your online retention and vice versa. 

This is a HUGE topic and I highly recommend checking out some of the CJA implementation content on Experience League to help answer it further. A member of my team put this together a couple of months ago: https://experienceleague.adobe.com/docs/analytics-platform/using/cja-data-ingestion/data-ingestion.html?lang=en

Hi Ben, 

Please guide me on how to track IP address of visitors via adobe analytics,i am unable to do it

Hi David. You have officially exceeded my understanding of Adobe Target 😂

I've got a question in to my friends who work on Adobe Target to find an answer for you. Stay tuned. 

You're already in the event! It's just this. . . I think. I hope. Otherwise, I'm in the wrong place. 

Hello there. This could be a few things, I think. First, make doubly sure that you are choosing the right IP address field (I'm assuming you only have one, but you'd be surprised), and the right report suite (i.e., one that has data flowing into it). Second, I'm not 100% sure we automatically hide the IP Address field in DW if you have IP Obfuscation turned on, so that is what I would check next. If IP Obfuscation is on, I wouldn't be surprised if we simply didn't return IP addresses via DW. Third, if none of those is a factor, I think I would probably go straight to Customer Care with this, because IP address should be automatically populated on every hit. Customer Care should be able to look at the clickstream data for you and confirm that we're collecting IP addresses in that report suite, and then work with our Engineering team if there is an issue. 

Hi there. We introduced a feature not too long ago (late last year?) that makes this a bit easier. If you go to the Flow visualization in Analysis Workspace, you can now start by dragging your conversion event in question (orders, signups, video completes, etc.) as the end point and then work backward to the "most used path" by clicking on each of the top "previous step" items as far back as you want to go. Here's an example of what that looks like after I clicked a few previous steps to get a bigger "tree:"