Identity Graph Use Cases and Troubleshooting

Transcript

Hello everyone, we’re just giving a couple of minutes for waiting people joining.

Thank you for joining right now, we are still waiting a couple of minutes.

Just give us just one more minute to wait for people to join in.

Right, I think better to start, we have a loaded session today. Hello all, good evening, good morning, welcome and thank you for joining today’s session focused on identity graph rules deep dive for AP users. My name is Sadev Tetic and I work in Adobe’s Ultimate Success team as Senior Customer Success Strategist, where we focus on helping Adobe customers get as much as value as possible from their Adobe solutions. Today’s session has been prepared for you by my colleague Senior Customer Success Architect Richard Childs. Before we go ahead and kick off the webinar, thank you for your time and attendance today. Just to note that this session is being recorded and the link to the recording will be sent out to everyone who registered in the session.

This is a live webinar, it is a listen only format, but do feel free to share any question into the chat or Q&A pod. We will monitor the pod and chat and answer it as much as we can, or we will have a reserved time to discuss questions at the end of the session.

There are a few, while we are waiting for the attendees to enter, a few information about the upcoming virtual events we have in September and October.

I will definitely put the links in the chat when we come into the presentation mode so you will have a chance to see the links again. You see that we have pretty much prepared a nice little webinar for you in the coming days. This is an on-demand library on Experience League, to give you some ideas about what could be an interesting reading material and knowledge information for you.

Lastly, we just want to talk about a little bit of ultimate success. What you see on this slide is the foundation of our ultimate success model, which combines proactive strategic leadership with responsive technical support to help customers maximize value and maintain stability with their Adobe solutions. On the proactive side, we work with your teams to align a unified success plan, execute targeted accelerators, and support your roadmap through expert-led activities across technical health, strategic planning, and event readiness. At the same time, we are here to ensure rapid response when needed. Our responsive model includes dedicated support resources, subject matter experts who monitor, prioritize, and resolve issues swiftly, whether it’s a P1 incident or ongoing incident analysis. Together, this approach ensures you are not only covered for today’s needs, but are continuously moving forward to long-term success and linearization.

Thank you very much for this short introduction, Richard. I’m handing over to you now.

Good afternoon, everyone. Thank you, Sarah, for the introduction. Today’s webinar is focused on identity graph rules within the customer data platform. Our session will examine exactly how the identity graph brings together distinct customer profiles and enhances accuracy.

I tend to clarify the decisions involved in setting up the identity graph, explain how the mechanism itself operates, and dispel any myths about it being a black box or just purely a technical question.

There are genuine business implications, and a thorough understanding is critical, not just for the technical teams, but for the business users as well. The central use case involves improvement of the customer profile and the unification of it.

So why do identity graphs matter? To begin, let’s discuss the primary drivers for identity graph linking. These are scenarios where customers interact across multiple devices and channels, perhaps switching between a mobile application, the web browser, or even shopping installed whilst using a loyalty card. These interactions are no longer isolated. It’s possible to link them, enriching our picture of the customer.

Consider someone visiting a website anonymously, then registering or logging on later. Merging interactions from all channels, digital and offline, enables you to construct a more comprehensive profile.

Many professionals take part in shaping the identity graph rules in order to understand the mechanism by which customer data is unified. Throughout this session, I will clarify which responsibilities fall to the identity service, which are the remit of the profile service, and also what pitfalls may occur if they’re misconfigured. These considerations frequently shape business decisions and governance of customer data management.

So let’s start with the comparison of the identity service and the profile service, the real-time customer profile.

The identity service on the left, this is there to build identity graphs. Its task is to link identities like email addresses, loyalty IDs, CRM IDs, cookies, using available inputs from data ingestion or time series events.

Crucially, for identity resolution to function, incoming records must contain at least two identifiers. Otherwise, meaningful linkage cannot occur. When paired, these identifiers form the nodes and edges of the identity graph.

The profile service then takes over and it leverages the profile fragments that it has, the records it’s able to pick up of the interactions on a single channel, and the identity graphs and link them together.

These fragments originate from myriad events, websites, purchases, back-end CRM records, and allow us to realise a full spectrum of customer attributes and behaviours. Once we’ve got the unified merged profile, what constitutes the profile data? So it comprises four bits, and it’s called profile holds attributes, static facts like the postal address, age, name and gender. Alongside these, it holds behavioural data, tracked website visits, purchased products and actions undertaken.

The third element is the identities, which is the map connecting the touch points and devices. And finally, the profiles are segmented by the business for activation.

This is where you group together customers according to behaviours or demographics for marketing or analytical purposes. And these elements are unified, a true 360 degree view of the customer emerges.

So let’s look at that from the point of view of the channels.

You consider all these channels, web, mobile, post, contacts, centres, retail stores, data from external databases or third parties. While each offers only a fragment of the total customer story, identity stitching joins these fragments into a coherent customer profile.

And the backbone of that is the identity service. All those different types of IDs, the IP addresses, device IDs, email addresses, phone numbers, cookies, etc. Each must be mapped accurately. For example, cookies may shift or disappear, while CRM IDs tend to be more stable.

The challenge is to ensure that these disparate identifiers are crisply linked to the graph.

So the first step is to build the identity graph. This is a two step identity resolution process. First, pairs of identifiers are captured from a customer’s journey, email, phone purchases, logins, and they’re merged into the identity graph to unify the profile. Establishing uniqueness is essential. Cookies, for example, cannot be assumed to be unique, whilst CRM IDs typically are.

Whether an email is unique may depend on your business context. Some customers may update their email over time, and the system must accommodate this reality.

In a B2B scenario, multiple contacts might be set part of the same account. So all decisions are actually business logic, not just simply technical rules.

Once we’ve got the identity graph, then the profile service uses merge policies to build a unified profile.

They are linked by their identities and then drawn together. So the merge policies become relevant now. They dictate how to resolve conflicts, whether to lean on a most recent interaction or timestamp for particular events and behaviors, that’s timestamp ordered, or whether there’s data set precedence where one data set or maybe customer attributes is more authoritative than the other. So both mechanisms play a crucial role in shaping the outcomes, so designers must exercise deliberate judgment.

So this is what the identity graph looks like, or at least it’s the visualization and user interface, the identity graph viewer, helping you debug and refine rules. So there’s a simulator in the user interface. Using the simulator, you can observe how identities and links evolve, a valuable resource for testing, validating your rule configurations.

The viewer allows you to drag and interact with different parts of the graph, allowing you to examine complex identity relationships, debug more effectively, and benefit from increased transparency with how information is being utilized. An identity graph is a map of relationships between different identities for a particular customer, providing you with a visual representation of how your customer interacts with your brand across different channels.

All customer identity graphs are effectively managed and updated by the Adobe Experience Platform Identity Service in near real time in response to customer activity. The identity graph viewer in the platform user interface allows you to visualize and better understand what customer identities are stitched together and in what ways.

The viewer allows you to drag and interact with different parts of the graph, allowing you to examine complex identity relationships, debug more efficiently, and benefit from increased transparency with how your information is being utilized.

So the importance of understanding the rules. Rules may have been set for your RDCDP instance during implementation, perhaps by your by a consulting team or internal stakeholders, but familiarity is vital. These rules reflect business priorities. The marketing team will want profiles rich in behavioral data tied to contactable identities like email. The loyal team might want to anchor the graph on loyalty ID. The data governance may enforce CRM ID as the master key.

GDPR compliance adds further nuance. If two different email addresses are treated as separate profiles, even though they’re for the same person because they changed over time, a data request may only partially fulfill the regulatory obligations.

Ultimately, priority namespace as a business is a business, not a technical decision.

So imagine you are a large multiline real retailer with three primary identifiers for customers, email address, loyalty card number, and CRM ID.

Which identifier should have the highest namespace priority? Which should be unique and drive profile stitching? It’s not an obvious order. The business must decide, for example, whether a customer’s profile should be split if someone gets a new loyalty card, but keeps their email or vice versa. This can deeply affect reporting attribution and marketing campaign eligibility.

Because the ordering changes how profiles are formed and which entities will be merged or split, it can have profound effects on customer experiences, reporting accuracy, privacy risk, and business processes. The right order is rarely obvious and must be tailored to each enterprise’s business model and priorities, not just the technical behavior of the system.

Let’s explore identity namespaces.

That is how the system knows that two profiles should be linked along those lines, but there are different types of them.

Cookie IDs, they used to identify web browsers, essentially tracking the device and session when a customer is using or visiting your website. These identities play crucial role in expanding our identity graph and often constitute a large proportion of the identities within your system. However, it’s important to note their limitations. By their very nature, cookie IDs are transient. They have a short lifespan.

People frequently clear cookies, switch browsers, or use privacy modes, meaning these IDs decay. They lose their value quite rapidly over time. Therefore, though cookie IDs allow us to capture large amounts of anonymous behavioral data, we cannot always rely on them as permanent or unique identifiers for profiling an individual. They’re best used as connectors to others, more suitable identifiers, and should always anticipate eventual attrition in your cookie graph.

Moving on, we come to cross-device IDs. These IDs are fundamentally different. They’re designed specifically to identify individuals, and importantly, they tie together other types of IDs, such as logon IDs, CRM IDs, and loyalty IDs.

A cross-device ID is pivotal within your identity graph. It’s the glue that binds disparate channels and devices, permitting the assembly of a consistent customer view, regardless of where the customer engages.

When the system identifies a cross-device ID, it recognizes the need to handle it with particular sensitivity.

For example, a login credential will often link a user to their purchase history, newsletter subscription, and browsing habits across multiple devices. This is why cross-device IDs are treated as privileged within the identity service. They underpin much of the logic that enables true person-centric profiles.

Next, let’s discuss device IDs. Device IDs are markers for hardware devices themselves. Examples include Apple’s IDFA for iPhones, iPads, Google’s GAID for Android devices, and RIDA for Roku streaming services.

These identifiers are robust because they’re directly linked to the hardware, but an important caveat remains that devices are often shared. For example, multiple people in a household may use the same tablet or smart TV. In these cases, a device ID alone cannot be assumed to represent a single person.

It can signify the presence of shared usage, and you should configure your identity graph to reflect this, with merging policies, for example, that account for communal devices.

Email addresses. In most instances, an email address is associated with a single individual, making it an extremely reliable market for cross-channel marketing. It ties together behavior from mobile apps, online shopping, loyalty programs, and more.

Email addresses, however, carry personally identifiable information, and with that comes compliance responsibility. When the identity service detects an email address and identifies, it recognizes that this is sensitive data, subject to GDPR and other regulatory requirements. Good practices include validating email addresses upon capture and ensuring that your systems use the appropriate level of security.

The last on this slide is non-people identifiers. These are examples of things like product SKUs and organization codes or store ID.

They do require an identity namespace when they’re ingested, but they’re not linked to the person clustered within the graph. For example, you might track sales across stores and products, but these identifiers are used for linking operational data, not forming customer profiles.

Two more. Partner IDs are slightly more complex. They are identifiers provided by data partners, perhaps for audience extension or enrichment. They represent people in a pseudo-anonymous manner. Instead of revealing the true identity, partner IDs may be hashed values or probabilistic methods to avoid sharing actual personal information. Within RDCDP, the main use of partner ID is for audience activation and data enrichment, not for building new linkages within your core identity graph.

As a safeguard, Adobe System does not generate new identity graphs when ingesting namespace is marked as the partner ID type. In other words, you cannot use these identifiers to merge or expand your graph of customer relationships. Failure to ingest partner data with the proper partner ID configuration can have serious consequences.

It can result in breaching system graph limitations and unwanted merging of profiles, essentially polluting your identity graph with erroneous connections. Therefore, always flag partner data correctly and ensure it’s used for its intended purpose.

And finally, this phone number. It functions much like email in many respects. Phone numbers are often person specific and used across multiple channels, making them strong candidates for linking profile fragments together.

Profile numbers are also classified as PII.

When the identity service encounters a phone number in the identity graph, it treats it sensitive and ensures it is managed in accordance with both internal policy and external regulations.

Reliability.

In summary, each namespace type plays a unique and sometimes complex role in the identity system. Correct classification and configuration are essential not only for compliance, but also for maximizing the business value of your customer data.

By understanding the distinct properties and limitations of each type, you can confidently design your identity graph by accuracy, privacy and operation efficiency.

I’ve included some further reading which will be available when you get the deck later.

More notes on identity namespaces and identity switching. I’d now like to show you a demo, dive into the user interface and show you more about the simulator that allows you to visualize the identity graph.

So in the user interface, you would come into Adobe Experience Platform. Down here on the left hand side, you’ve got the identities service down here. And you come into this summary screen, which I’ll talk about a bit later.

On the top, you’ve got four tabs. On the last tab, graph simulation. This is where you can use the simulation service to work through scenarios that are likely to come up when you’re implementing or maybe for debugging a scenario where you had an unexpected graph collapse and you’re trying to understand why. So you add in a sequence of events that the customer has taken through, a number of activities. So it could be it’s just the identities. It’s just what was captured by all those activities when they browse, when they logged in or whatever. So you can add in activities one by one through the user interface or there is a text mode, which is easier for me because I’m just going to paste my demo data into it.

Then I can switch back to the normal GUI. So that’s how that’s how it would appear if you’re manually entering it all in. Then you need to add in the configuration that you’re going to test out. So all your identity namespaces are already defined in your sandbox.

So you pick from there, from values, which ones and in what order you need to simulate.

Pick out the ones that are in this list.

And you need to select which ones are unique. So that’s where it can detect that the identity graph has collapsed and split off the graph into two or three or four to ensure that uniqueness is enforced. Having done that, I can then go ahead and press simulate.

And it draws me an identity graph for this set of data.

So you can see here the identity graph. It’s got some solid lines and some dotted lines.

It shows each of the IDs and how they’re linked to other IDs. And you can see that essentially it’s severed three of the connections in the middle, ones labeled five, one, six. So you basically created two graphs as the result. It’s got one that’s only got the CRM ID of DEF and IDFA of 111.

And on the other side, it’s got one that contains two email addresses, two cookies and a CRM ID.

So the number is the order in which they were created, the activity orders listed on the left hand side. So initially those were linked, but then it became apparent it had to sever that link.

And more information came to hand. So it could be that two people were sharing the same device.

The system assumed that it was a continuation of the first person using the device. But then when the second person logged in, it became apparent that a lot of the work that was being done on that device was behavior that should be attributed to the second person because they logged in and found out the CRM ID was different. So you need that’s why you needed to sever the graph, because if you wanted to do some kind of behavioral targeting, you want to make sure that you target each of those two customers who were sharing the same device based on what they actually did, not what each other did.

You can see that within this right hand profile, there are two email addresses. So that could be perfectly valid in your business model. It could be that you allow customers to change their email addresses and the customer happened to, you know, get fed up with their email provider, change email provider, and they have changed their email address and expect to be have an unbroken service from you and still get relevant prompts and marketing from you.

But we could have a look at what happens if you change the ordering. So if instead of CRM ID first, we put email ID first to make that unique, then we can rerun the simulation and we get a different graph just by making that change. Same events have happened.

Same two people have used the same two devices, but we get a different graph. So in this one, you can see these red dotted lines are all severed.

They so on the top, top half of the screen, we’ve got. Email Richard, ECID 333, CRM ID ABC, and on the bottom half, we’ve got two IDFA’s. Then we’ve got IDFA 222, Giles, ECID 111, DEF is the CRM ID. Now we’ve got two different groups.

I guess they’ve shared the behavior data a bit more fairly.

That may or may not mean we’ve got a clearer picture of what each of them did. You’ve got to decide that based on your your business rules. So maybe in order to understand even better.

The point at which the graphs were split. You can actually use this slider on the top right. You can roll the events one at a time, making sure you understand how the identity graph is built up and the moment at which the identity graph collapsed and had to be split.

So if I scroll that back to six, I’m only going to run the first six events in the activity list.

You can see rearrange it.

You can see up to this point.

Most of the activity online was all linked to the Giles profile with.

Richard, Richard just stranded on its own. So that probably means that you’ve got some customer attributes for Richard, Richard, but no behavioral data, no events.

But you’ve got much more behavioral events that were currently linked to Giles and Giles by then move forward to the next interaction. That’s the point at which the identity collapse, the graph collapsed and the two was split into two distinct identity graphs, which will be which will end up in RDCDP as two distinct profiles.

So periodic simulation is the best practice whenever significant business process changes are proposed.

And it can serve as an ongoing task. And obviously, in the original design phase, you could test out some what if scenarios with the way in which you intended to tag your different platforms. Once you’ve decided on your algorithm configuration, then you need to implement it for real. This simulator does not export. It doesn’t even have a save button. So what you do is you’ve got settings here. The top right.

Provides you the list of the real namespaces that are in your implementation, and you would reorder them in line with what you had just been testing and just decided so two tables. First one is the person namespaces.

So put email and CRM ID up there at the top.

The second table is for device and cookie namespaces.

Ones that are more anonymous.

So we put the ones we put in there. That’s next.

More caveats. And then we have the consolidated list of all of the namespace priorities, and then you would press finish.

Let’s talk more about graph collapse.

So there are some common challenges or typical problems. Graph collapse arises when multiple profiles emerged, often due to shared devices, which mainly I was talking about in the demo. Family computers, library kiosks or call center terminals. This models individual customer histories.

So you can see there they’ve got three people all using the same computer.

Hazards extend to validation lapses. Unvalidated emails and phone numbers can corrupt the graph, clustering unrelated behaviors. So if you allow customers to put in rubbish as a phone number, then a lot of customers might put 9111111 as a phone number and all the people who did the same random phone number would would collapse if you use that as a call center.

And you can also have implementation errors, bad values captured by poor implementation. For example, if if a field was missing, instead of not sending it at all, your implementation might inadvertently send a string like literally the word null. And then everybody who had null in their data that was used as a namespace in the identity graph, where data would be joined together. So anybody who’s who visited the page or whatever that had the dodgy data in it.

We want to know how to fix these three scenarios. Remediation depends on configuring accurate graph linking rules. Use the simulator to model real world scenarios, ensuring your rule choices yield correct graphs. Once validated, implement your namespace priority decisions with the live identity service settings. Personal namespaces such as email, email and CRMID would take precedence, followed by device based identifiers. Confirm, review and apply these selections to optimize your configuration for business needs.

I’ll just recap on the.

Those concepts that we’ve discussed in the demo. So the key concepts are unique namespace, that’s the ones that are flagged as being completely unique within a graph there. That uniqueness is not upheld, then the graph knows to automatically split. The namespace priority.

Is.

The order in which those rules are applied. Determining which identifies prevail in conflicts, the identity optimization algorithm is the whole thing, the process and the logic for resolving conflicts and consolidating valid profiles.

So this is done in a layered approach.

The system builds from the top priority namespace down, merging data until all available pairs are resolved or nodes are pruned to maintain uniqueness. A unique namespace determines the links that get removed if the graph collapse occurs.

Examples in practice. Here’s how the process operates in an actual scenario. Events are processed in sequence, namespace priorities are applied and the resulting graph represents the true structure of custom identity across channels.

Most common configuration. Is to have a unique identity. And for this to be the highest priority CRM ID, we discover that CRMD namespaces uses the primary identity in a schema that also includes first and last name, address, birth, data, etc. This is the most typical of cross device namespaces that we configure as a unique namespace with a new linking features.

If you don’t immediately see the primary identity of a schema containing a person’s name, then search for the field name first name within the object hierarchy of person name first name. This comes from the personal contact details field group and the primary identity of a scheme that includes that field group is a good candidate to be labeled as unique in the linking rules configuration. Same is true for the demographic details field group if it’s in using the schemas email address. That’s number two. So we’re building up the profile in layers. The layers are groupings that basically corresponds to the namespace priority.

So.

If we use the email as a primary identity, this is we have to decide if that’s valid. It is only valid if no person can ever change their email address on the account. If you register with one email address, you won’t be able to change it later.

Something else or we don’t care about email address and it’s perfectly fine that the email address and its data will push older email addresses out along with their profile. So it doesn’t matter if we’ve got a sort of a rolling window of behavioral data we’re interested in. If we don’t mind losing real data that was linked to older email addresses.

So we have some solutions for our three. Graph collapse scenarios.

For shared devices.

Only the events with the latest user reflected in the profile for that device.

And that into the optimization algorithm gives us that for unreliable identifiers such as the non unique email phone numbers.

We can do validation, send an email so that you have to confirm it, sends it back to the website, and we’ve proven that that’s a valid email rather than just relying on validating the formats, particularly phone number formats. You could just validate phone number formats or you could send an SMS that has to be clicked on to get back to the website and validate the phone number.

And for implementation, obviously apart from implementing it properly, but to understand the reliability of CRM IDs. Are they deterministic? Does every customer have one? Is there any validation you could do on top of it? Another layer in the technology stack.

Even though you’re integrating systems, you should still have sort of a some validation when accepting data from other systems.

We’ve got a couple of words on implementation.

Not much. There is a comprehensive documentation available for configuring your identity graph. As demonstrated, validating rules with simulator is advisable before going live. Capture only necessary identifiers at each point. Avoid superfluous or ambiguous fields.

The critical touch points such as logins ensure strong pairing easy cross device ID with verified cookie.

Maximizing the linkage, but preserving identity clarity.

So what happens if it’s already gone wrong? So if we’ve got historical profiles that have collapses that have now been stored in the system, what do we do about it? So first of all, check whether the repair is required. Those graphs that were on the first page of the screen when I was doing the demo. They show some metrics that can indicate this.

Within the interface, it’s crucial to modify it. Monitor for collapsed graphs.

By clicking the options icon besides graphs with multiple identities by namespace.

One can quickly ascertain the presence of graph collapses. If the namespace marked as unique is not zero, this flags that collapsed graphs exist, warranting repair.

For example, you should notice 14 collapsed graphs in your environment indicating 14 profiles bearing more than one CRM ID. Requesting a repair job is prudent.

Conversely, if your unique namespace count is zero, there are no collapsed graphs and no further action is required.

Once a team reviews and approves a repair operation, your account or delivery team can raise a formal request for a collapsed graph repair job. This job specifically triggers targeted link deletion within the graphs designed to restore correct segmentation. Typical turnaround for processing such jobs is two weeks in a production sandbox. Adobe engineering undertakes this deletion operation manually.

Graph repair operations are conducted as a one off process by engineering. The specific goal is to ensure that all profiles can be effectively segmented and activated according to business requirements. Focusing only on production sandboxes. The methodology involves surgical deletion of problematic links in collapsed graphs based on identity settings. Unique namespaces and their priority order.

Duration depends on the overall volume of data in the graphs and the identities present.

So when new or updated identity settings are enabled, fresh graphs will not collapse. However, pre-existing unmodified graphs remain collapsed, potentially muddling segmentation efforts.

So that’s why we need to delete the data and reprocess it.

So some operational considerations. It takes two weeks.

It’s a one time graph repair.

Production sandboxes only, I believe.

And it’s to ensure all known profiles are segmented and activated. It deletes links in the collapsed graphs based on your identity settings and new ones.

So I’d just like to summarize the key takeaways for this session.

Always appreciate the specifics of your platform’s implementation, even if you were not directly involved. Any modifications such as changing identity technologies or removing valid email validation may disrupt the integrity of the identity services.

It’s wise to anticipate and plan for necessary revisions as your digital estate evolves, especially when major updates to websites or applications occur. Remember, for a large scale data cleansing or graph collapse issue, Adobe can offer targeted assistance. Prioritize strategic thought about profiles before introducing new identities. Consider deeply what customer information is most vital and ensure your platform design is robust, accurate and future proof.

Thank you very much for joining. I encourage questions. Please do share any scenarios you’ve encountered or cases you wish you would like to model.

Your input ensures that we can have a better discussion about what your individual question and problem is. Thank you very much, Richard. As we get in the Q&A portion of the event, I’ll be posting a quick three question poll launch in the chat. But before that, we have three questions, Richard. The first question is, is it possible to use the loyalty ID or CRM ID for stitching as we cannot use email ID for stitching? I’m enduring the presentation. You highlight this possibility.

Yes. That was the main way we started off. So you can obviously have multiple identities as unique as well. So if you wanted to start with the loyalty ID as the highest priority one, that’s perfectly fine. That’s how I started the demo. It’s just that in the case of my test data, I wanted to demonstrate that that resulted in duplicate emails. But if you if you flagged the the emails as also duplicate, then you’d get uniqueness in both respects. It’s as I said in one of the slides, CRM ID is probably the most common, highest priority namespace for linking in most implementations.

The second question we have is during your demo presentation, the simulation of the graph. Did the severance happen because we define CRM ID to be unique paragraph? And what happens if you don’t select any ID as unique paragraph? At least one. But if you don’t, then then you are. But if if you don’t select anything as unique, then there would be no reason to split the graph.

OK, so the that I mean, the simulator says you should have one, but I think in that sandbox, none of them is currently set to.

Unique, you actually go back in here. In this.

In here, it seems like none of them are actually set to unique, and that may also be the reason why, if you then go to the overview in these graphs that you can use to identify whether graphs have collapsed, you’ve got.

You do have claps, because.

We’ve got it’s only test data, 195 is actually all of the models, I think, certainly quite a large number. You’ve got a large number of CRM IDs there. With 195.

Profiles with multiple CRM IDs, largely because they weren’t flagged as unique. So you can still you can still do it if you think that that’s relevant to your business.

Thank you. The last question about is how does AP handle conflicting or duplicate identity information from multiple sources? Name stays the idea is most probably namespace priority, right? So it’s the same namespace, but from a different data source. So it’s it’s. It’s based on the timestamp. So the.

The latest information.

I’m trying to think of the scenario you’d have to have both ideas the same from the same place.

I’d have to think what’s that scenario is if you have two sources, both say that I’m talking about John, how do you know one of them wasn’t really talking about John? So you’d need two pairs of identities where.

Each of these data sources had two namespaces, and therefore there would still be a namespace priority precedence if you’ve only got one namespace.

It doesn’t affect the identity graph that the identity graph only works where there are two namespaces. In the profile service, that’s when you need to resolve conflicts where you’ve already established that both data sources are supplying data for John. And then you need to decide is is that is it data set precedence, meaning I’m going to trust this data source more than this data source? Or is it time stamp based, in which case I will take the latest one in terms of building the identity graph. You can only build the identity graph from pairs of IDs, so you must have already decided which carries the greater weight when ingesting that data.

Not sure if that answers the question.

Thank you. There is a question in the chat. Do any capabilities exist for householding or is it all individually focused for one to one contact? I think I might need to take that away. I can’t remember off the top of my head how the rules differ for B2B solutions. That’s effectively what it is. It’s the B2B solution. So I’ll take that away, I think, if there’s any difference in the ways those rules should have been applied.

One question more. Is there a way to identify when a device ID is associated with multiple consumers and use that data to explain how this impacts our CRM strategy? This is the market. What’s the CRM strategy? We are thinking about moving the decision to remove it. Most probably it is using the same different users using the same device ID. So it’s just you mentioned in the simulation, if the device ID is the identifier, it might end up with multiple users having the same behavior. I thought you were saying there were multiple devices to the same CRM ID. Can you read the question again? Is there a way to identify when a device ID is associated with multiple consumers, one ID with multiple consumers? That is the scenario we had. If you need to split the, you know, you have, if your CRM ID is unique, then you’ll split the graph on the lower priority namespaces like the device ID. And unless you’ve got newer data that associates those pairs of CRM IDs with device IDs, then you’re not going to be able to attach that behavior data to a CRM ID. It will sit there as anonymous ID. So you can’t basically be confident of who’s using the device. I mean, even if somebody else didn’t log in, until somebody logs in, you don’t know whether to assume that it’s the same person continuing to log to use the device or a new person, unless you continually reassert that this is the CRM ID of the person who’s using the device. Are they still logged in? Are they soft logged in? Or are they logged out? And so are you going to make a working assumption that they’re soft logged in and risk it that somebody else could be using the device? Or are you going to say, well, they’re completely logged out. It’s now anonymous browsing behavior, which I can’t associate with a person until they log in again.

Absolutely.

Anybody, I’m just looking at the last question. That’s all the questions we have, but we can give a couple of minutes. We still have time. If you have any questions, please tap on the Q&A or chat.

One question. Do we have a limit on the number of the IDs that can exist in an ID graph? I’m sure there’s a guardrails page, I think, probably online and we’ll save all that is. We look for guardrails in the documentation.

Another one for you. What is the process to re-ingesting clean data if first attempt had bad data? I think that’s the scenario where you need help from Adobe to run an engineering job to clean it.

Unless you just drop the data set. If you have the ability to play back the data after you’ve dropped the data set. Otherwise, it is an engineering job.

I think there is a suggestion right now for the next follow-up meeting. Will there be a separate session on profile merge rule and best practices around that? We’ll take it into consideration and we’ll come back to you. Thank you very much for the suggestion.

Last question for you, Richard, is generally for us. Yeah, I don’t think I need to answer that one myself.

Okay, I think, let me check it one more time.

There’s another tool you could use for debugging this graph viewer. If you have got a specific cookie or something, you could put it in here and actually cut and paste the cookie in there, cut and paste the CRM ID in there and look at an individual graph as a test case if there was a problem.

Well, thank you, Richard. Thank you everybody for all your taking time to join the session today. We hope to have your company again and in future webinars. Thank you very much for filling the poll and have a great day. Thank you. Bye.