Hi James, moving this to our discussion forum for others to weigh in!

Hi @James Larsen,

Interesting question!

You wrote:

we're still landing at about 48% of our customers signed up with no visibility into any pre-sign up activity 

What exactly do you mean by that?  And how do you have your sources and Unify IDs configured?  Would be helpful to have more background/context.  Are there not sources flowing some form of identity upstream of your app?  We’re wrestling with a similar but seemingly different challenge, so I’m curious.

Thanks,

Chris

So we’re relying on the Canonical IDs to eventually get a payload with a proper “user_id” in it to be our internal customer ID.  We have thousands of canonical IDs that we see web activity for, with no user_id.  We checked a subset of the Canonical IDs that we do have a valid “user_id” for (so signed-up customers), but 48% of those Canonical IDs aren’t linked to any other pre-sign up activity (ad clicks, web page views, etc.)  So my belief is that their activity is there, but without enough information to properly merge segment IDs with web activity to segment IDs with the user_id, but just trying to determine how normal a gap that big is.  Hope that clarifies things a bit.

To me it seems that your web doesn’t (always) pass the anon ID to your app. Could you elaborate a bit on how this flow looks and how your Unify is configured?

So I’m somewhat new to Segment, but I’ll try to describe what I understand so far.  We have two main sources we rely on: “Web Server” and “Production Server”, with both passing through Unify.  Below is our space setup.

Both sources have a “user_id” field.  On Web, it’s a hash of their phone number (on events where we know their phone number).  On production server, it’s their true user ID assigned within our system (which we also send the same value as “customer_id” on those identify calls).  We rely on the identifies call on production server to link their segment ID to their assigned user_id.  I did confirm that the identifies calls on production server seem to almost never have an anonymous_id, so we’re likely relying on other identifiers like phone and android.id for identify resolution.  I’m opening a discussion with my colleague about if we have any control over including the anonymous_id on the production server identify calls.  Let me know if I can provide any additional details, and appreciate the help.

 

Based on this info, i’d say you need to pass the hashed phone number as user_id on your production server instead of the actual customer id on user_id. Otherwise there is no way for Unify to tie a customer with a “hased phonenumber” as user_id to an identify call which only has the actual “customer ID” as user_id

I think in the cases where Unify was able to tie them together was indeed based on any of the many other identifiers that you pass which were populated by both sources. It could be that on these 48% affected profiles, these identifiers are not populated on both sources.

I’m not sure how much that will help.  For both the Web and Production identify calls, they both already contain the phone number (when available), which is one of our identity resolution fields.  So I’d assume for cases where we know their phone number on web, and it saw the same phone number on the production identify call, it should be able to tie those segment IDs.

I suspect most of our gaps come from web activity where we don’t capture the phone number.  As you mentioned and I was able to confirm, our production identifies call doesn’t seem to almost ever have an anonymous_id, which if we can solve, might be the missing piece of the puzzle.  I just don’t know enough about when Segment creates an anonymous_id and when they don’t to determine why that field is mostly blank on our production server identifies calls, but I can start my investigation there.