RT CDP Profiles timing for stitching/merging.

[AlexandreSa8]

Hi, everyone.
I have a use case where I need to wait for the RT CDP Profiles to be stitched or merged before using them in an AJO Journey. While I wait for this to happen, I need to minimize the waiting time, which is currently over 40 minutes. I'm wondering if this is the best approach and what the ideal waiting time should be, based on real-life experience and guardrails.

[itsMeTechy]

if you trigger your journey based on audience qualification, then the profile must have stitched already. 

[AlexandreSa8]

Hi there.

It is actually an unauthenticated to authenticated, ECID event that should be stitched, based on durable identities, so I can use the profile data.

[marc_stowe_za]

Hi

if you are using an AJO unitary event type trigger then what i normally do is put a trigger on the event table and set a 30 second wait before it does much. So it triggers off the event datastream and waits 30 seconds which gives the profile enough time to stitch into the identity graph. If you are basing it on audiences when it should take more than about 30 minutes for the stream to push into the dataset and stitch, so your 40 minutes makes sense.

in the example above I send the profile and event info at the same time, but the graph needs to update hence the 30 second delay in the AJO journey.

[Sukrity_Wadhwa]

Hi @AlexandreSa8,

Was the given solution by @marc_stowe_za helpful to resolve your query or do you still need more help here? Do let us know. In case the given solution was helpful, then kindly choose it as the 'Correct Reply'.

Thanks!

[AlexandreSa8]

Thank you for your reply.
In my case, I'm only using form submission events.
Before form submission, I have only the ECID, but after, I'm also pushing the hashed email into the identityMap object.
From my observation, the identity stitching of this ECID profile with the hashed email takes up to 30 minutes (even 40 minutes).
I have a form submission event-triggered journey, a 40-minute wait, and a condition to verify a specific attribute in the hashed email profile. If it is there, I'm assuming this hashed email is preexisting and not a new one, and this forces the journey to a different path.