Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge tracking capabilities of Sapience #27

Open
zarathustra323 opened this issue Oct 19, 2016 · 0 comments
Open

Merge tracking capabilities of Sapience #27

zarathustra323 opened this issue Oct 19, 2016 · 0 comments

Comments

@zarathustra323
Copy link
Member

zarathustra323 commented Oct 19, 2016

To do: Per #26, the tracking functionality of the Sapience library needs to be integrated within the Radix JS. Once this has been resolved, all changes in #26 should be reverted/removed.

Since Sapience lives on a separate domain from Radix, the two libraries cannot share/read each other's cookies. As such, temporary measures were implemented to support setting the active Radix customer as the active Sapience identity.

Once the Sapience backend tracking mechanism (and subsequent front-end JS) is merged, Radix will have native front-end JS tracking calls, as well as have back-end access to the active customer cookies, without the need for front-end assistance.

Ultimately, the front-end Sapience JS should be "thrown out" and replaced with a forked version of Segmet.io's tracker (along with additional React/Flux/etc magic).

In addition, when a customer should be tracked, and which cookies should be used, is up for debate.

  • Status Quo
    • When a customer account is logged-in, the visitor and session cookies are set to this account
    • When a customer account logs out, the visitor and session cookies are purged, leaving no associated identity traces
    • When an identity is detected and/or created, the visitor and session cookies are set to the customer identity in question
    • The visitor cookie is considered persistent; the session cookie will expire after 24 hours of inactivity
    • Generally speaking, tracking has always been based on the visitor (persistent) cookie.
  • Potential concerns...
    • When a customer account logs out, should the cookies be updated to reflect an associated identity? This would allow for continued tracking, but not against the "canonical" customer account.
    • If this is the case, which identity should be chosen? Technically, an account can have more than one identity, due to the fact that a customer can have more than one verified email addresses.
    • Because the visitor cookie has such a long lifetime, would the session cookie be better for tracking? It would indicate a "more active" customer. Or do we flag the quality of the customer cookie found, e.g. flag a session event as "better" than a visitor event?

Finally, the concept of customer identities is still a bit elusive.

  • Should the identity use email address as its unique key? What about other uniqueness factors? External integration IDs, and the like?
  • Should we use some concept of a device signature?
  • For that matter, should identities be unique at all?
  • How does the identity source (a Radix form vs outside integration like a webhook or Omeda integration) factor into this?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant