LiftIgniter can be implemented on almost any device or platform, and can track behavior for a single user across all of those devices through a userId. As with most tracking tools, this works most easily when a user logs in to your site or service, positively identifying themselves. 


For LiftIgniter, you must use an ID other than their email address - we don't use or accept personally identifying information other than a user's IP address. We usually recommend using a UUID, but you can use any URL-safe ID format that you choose. 


UserIds in API Integrations

In an API integration you have complete control over all IDs sent to us and so your code will need to handle generating a unique value for a userId and storing it as a cookie on their browser and connecting it to any IDs being used to track them in apps or other platforms. You do NOT need to send a new userId to the /user endpoint prior to sending events to the /activity endpoint or requesting recommendations for it - as soon as a new unique userId is found, we begin building a new behavior history for that userId. 



UserIds in JS Integrations

In our Javascript integration, LiftIgniter will automatically assign a userId to a user and store it in their cookie. You can choose to either:

  1. overwrite the cookie value with an ID assigned by your own system or 
  2. extract our cookie value to use instead


It can be helpful to use a combination of both, depending on whether a user first becomes a known user (and tied to an email address or other PII that you collect) on the web or in an app.


Your System Assigns An ID

If you are already tracking your users cross-platform, chances are you already have an ID for them. For new customers just getting started with their LiftIgniter integration, this method is generally the best option.


On the web, if you are using our JS SDK you can overwrite the ID generated in the LiftIgniter user cookie with your own ID using the function $p("setUserId"). This can be triggered at any time after the LiftIgniter beacon and $p("init") function have been loaded on a page, and should generally be invoked on login or at signup. We generally recommend making this the first function used after $p("init"), before the $p("send", "pageview") event that is the standard next function to be loaded.


// ... Beacon
$p("init", "JS_KEY");
$p("setUserId", USER_ID); // USER_ID should be a string.
$p("send", "pageview");


Pros:

  • Consistent userIds across your systems
  • Can re-assign to a user as soon as they log in again if they clear their cookies

Cons

  • Any behavior history associated with that user while they were unknown (i.e. only had the LiftIgniter-assigned cookie value) is 'forgotten' when the userId is overwritten. For example if a user has browsed the site anonymously for several weeks before signing up for your newsletter, all of their pageviews and other activity from that time period would not carry over to the new ID assigned to them on signup.


Extract the LiftIgniter Cookie Value as the ID

When your user submits a form or logs in with their email address, you can use Javascript to extract the cookie and add the value to a hidden input field to act as the userID for them, rather than having your system assign them one. We recommend this method especially if you have already been using LiftIgniter for some time, or if you do not already have a method for generating and associating non-email-address userIds to your users.


The name of the cookie that you will need to extract is "_ig". Below is a sample script with one method of extracting the cookie and inputting the value into a specified form field.


<script>
try{
    $.cookie(“cookie name",'_ig'); 

if ($.cookie(“cookie name")) {                
    var cookieval = $.cookie(“cookie name");            
   var inputs = document.getElementById(“hidden-field");                                
    inputs.value =cookieval;
}
}catch(e){
    alert(e);
}
</script>


Pros:

  • Behavior history is retained for any 'anonymous' behavior prior to signup or login.

Cons

  • Some systems may not allow you to insert a userId of your own (you may need to give the field a separate name in your CRM and store the LiftIgniter ID there).


Using IDs Across Platforms

Once you know how your IDs will be generated and stored, you'll need to determine how and when they should be assigned to users. In general, this means additional checks on login or signup to see if the user a) already has an ID and b) to assign that ID to the user. The exact steps for doing this will depend on the systems involved, so unfortunately we cannot provide specific instructions here.


What happens if I don't match my users across platforms?

This is unlikely to have any negative impact on the experience of your users. In some cases, it might even be beneficial if users have drastically different browsing patterns and behaviors on mobile/app vs desktop (as is usually the case). In general, tracking across platform does not usually have a statistically significant impact on algorithm performance for normal recommendation widgets. However, if you plan on using our On-Open Email Recommendations service, it is very important to plan how you will be gathering userIds and associating them with the email addresses for your users.