Server-Side Identity Management

This article shows how to maintain a user’s identity in server-side, as well as hybrid server-side and client-side implementations. It also provides insights and strategies to ensure the identity of a user remains consistent through the interactions made with your site or app.

This article discusses two possible scenarios for your implementation: sending data only from the server, or from both the server and the client. Using these instructions, you can ensure user identity remains consistent across all server-side updates.

Server-side Only Implementations

Each event should have a Mixpanel distinct id to distinguish users. When a user is anonymous, you need to generate a distinct_id on the server, keep it consistent for each user, and send it with each event.

If your workflow supports identifying the user (signing up or logging in), you can then choose to either create an alias (PHP/Python/Ruby) for that anonymous ID, or continue to identify the user by the previous ID on your server.

Overall, a pure server-side implementation prevents major complications and it’s up to your server to determine the identity of a user at any given time.

Hybrid Server and Client Implementations

Some events are inherently related to client-side interactions (click a button), and some should normally reside on the server (store a transaction).

Arguably there can be overlap with certain type of events, so you’ll need to decide where an event will be recorded, depending on your specific use case.

For this example of a hybrid server and client implementation, let’s assume you have a common sign up workflow on a website (JavaScript and PHP). Part of this workflow is to load the sign up form on the client side and store the actual sign up on Mixpanel’s server.

Both events could be triggered server-side, but the former is traditionally located on the client–given that it can easily detect when a page has finished loading.

Triggering the sign up event on the server is useful as you can make sure it’s only triggered once upon success. You have the newly created ID available for aliasing, and you don’t have to cope with client issues, such as a user loading the confirmation page several times.

Since the event collection starts on the client side, you’ll want to send the user’s automatically generated distinct_id from the client side to the server for consistency.

Here’s a simple sign up form in JavaScript:

<form id="myForm" action="createUser.php" method="POST">
   <input type="hidden" name="distinct_id" value="" />
   <label for="name">Name:</label> <input type="text" id="name" name="name" /><br/>
   <label for="email">Email:</label> <input type="email" name="email" id="email" /><br/>
   <input type="submit" value="Submit" />
</form>

This sign up form only has two inputs, name and email, but there’s also a hidden field that will carry the distinct _id information to the server. Before the form sends the information to the server, you’ll want to populate the value of that field with the current distinct _id in previous events:

$(function(){
   var myForm = $("#myForm");
   //track the page load
   mixpanel.track("Page load", {"Page": "Signup Form"});

   /*
   Listen to the form being submitted;
   before it sends the request, the current distinct ID will be added
   */

   myForm.submit(function(event){
       var hiddenInput = myForm.find("input[name='distinct_id']");
       hiddenInput[0].value = mixpanel.get_distinct_id();
   });
});

The distinct_id is stored in the cookie by default with the Mixpanel JavaScript library, but passing it through the form simplifies this process, as there is no need to parse the cookie and then send to the server.

Once the form is submitted, the server will receive a payload with the user’s information, plus an additional field containing their distinct ID. With the information on the server and proper form validation, you can track the event and create an alias of the new ID on Mixpanel’s server.

After an alias has been created (client or server side), Mixpanel’s server does not need to keep track of the original distinct_ID anymore. You can use Mixpanel’s generated ID both on the server and client side. As a result, sending the alias creation request to Mixpanel is an operation that can take some time to resolve. To avoid any race conditions you should send any event and profile updates with the original distinct ID for two seconds after an alias is created.

Below, is sample PHP code to establish this alias and send events to Mixpanel with a consistent distinct_id:

// imaginary user class that takes the form submission
// information and stores it in the data base
require 'users.php';
$u = new UserClass();
//importing Mixpanel
require 'vendor/autoload.php';
$mp = Mixpanel::getInstance("MIXPANEL_PROJECT_TOKEN");
$result = registerUser(array(
   'name' => $_POST['name'],
   'email' => $_POST['email']
));
// the registerUser function will return
// 0 if there was an error or an ID for the user created
if($result > 0){
   // the user was correctly saved
   // we can trigger the event and create the alias
   // we send the events with the original distinct_id to prevent
   // any racing conditions related to using the alias before
   // it has been created
   $current_distinct_id = $_POST['distinct_id'];
   $mp->identify($current_distinct_id);
   $mp->track("Signup completed");
   //create the alias
   $mp->createAlias($current_distinct_id, $result);
}
//sending back a JSON response with the result
echo json_encode(array('result'=>$result));
?>

The step by step guide for the previous code is self contained in the code comments. But it’s important to review the overall concept:

  • Events were tracked on the client with a distinct_id.
  • The client sent information to the server with the current distinct_id.
  • The server processed the information, created an alias with a new ID, and sent it back to the client

As mentioned, this is a web environment. So PHP could have read the cookie in the request, as the distinct_id is stored in the cookie by default. But this approach is not taken in this case to illustrate purposely sending the said ID.

Reading the cookie is often not an option as the client could be a native mobile app, or you might be using local storage instead of cookies. So the best practice is to use Mixpanel methods to do the work for you.

When you have a hybrid server and client side implementation, it’s a two-way street where each component should communicate between one another to maintain identity.

Is this article helpful?
0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.