Alias, name_tag, untrack admin, upgrade to version 2.2

Thanks for the patch! It does a great many things, so this will take a bit to review. I'll probably have some questions/comments.

Anyone else getting a corrupt patch at line 10?

Marking as "needs review" - I still haven't taken a look at this..

Did reroll patch.

Hi,

Patch works great but as we can see its not reviewed yet. Anyone using for live site? can we use it. I tired adding patch and seems to work without any problem. Please suggest?

Thanks!

Has anyone confirmed that aliasing works as designed here?

My assumption: The main use-case of Mixpanel aliases is to associate events of an anonymous user who then generates a user account and does more stuff (so that we can monitor signup funnels).

I applied the patch (with some debugging) to the latest 7.x-1.x-dev, and I tried selecting both the uid and email as the alias, but I am still only getting events in my Mixpanel profiles for events after (and including) user creation. Events like clicking on CTAs to get to the signup page go through to Mixpanel, but are not associated with the post-user creation events. I send the user creation event in hook_user_insert like the mixpanel_defaults module does.

Apologies in advance for the lengthy post.

Just in case anybody runs into the same problem as I did, I've found a workaround, though it can probably be done more simply.

To re-iterate my problem: when using the 'alias to user id' config setting from this patch, I was not able to track the user account creation event as part of the same Mixpanel profile as the events before and after the user account creation. In other words, a CTA click or pageview in the signup flow and an 'upgrade membership' event (after signup) could all be attributed to the same Mixpanel profile, but not the actual user account creation event. So, we could not effectively monitor a signup funnel.

This is what mixpanel_defaults has, which is what I was mimicing:

/**
 * Implements hook_user_insert().
 */
function mixpanel_defaults_user_insert(&$edit, $account, $category) {
  mixpanel_track("user-inserted", NULL, $account);
}

The problem is, that hook runs around the same time that mixpanel.module is doing its aliasing magic, causing s*** to hit the fan.

The aliasing happens via a set of calls from hook_user_presave:

    if (isset($account->is_new) && $account->is_new == 1) {
      $edit['data']['mixpanel_login_count'] = 0;
    }

to hook_user_login:

    if (isset($account->data['mixpanel_login_count'])) {
      // Only set login_count after signup
      if ($account->data['mixpanel_login_count'] == 0) {
        $account->data['mixpanel_login_count'] = 1;
        user_save($account, $account->data);
      }
    }

to hook_init:

        elseif (isset($account->data['mixpanel_login_count']) && ($account->data['mixpanel_login_count'] == 1)) {
          // Set JS flag to perform alias
          $defaults_wrapped['defaults']['alias'] = TRUE;

          // Remove login_count from user data
          unset($account->data['mixpanel_login_count']);
          $save_data = TRUE;
        }

and then 'alias' is passed as a setting to mixpanel.js and mixpanel.alias() is fired.

Here's what I did, really just mimicing the method and namespacing of mixpanel_defaults:

/**
 * Implements hook_user_update().
 *
 * Here we set our own variable in $account->data once user_save is called by mixpanel_user_login
 */
function MYMODULE_user_update(&$edit, $account, $category) {
  $alias = variable_get('mixpanel_alias', MIXPANEL_ALIAS);
  if ($alias != '_none') {
    if (!isset($account->data['MYMODULE_login_count']) && isset($account->data['mixpanel_login_count'])) {
      if ($account->data['mixpanel_login_count'] == 1) {
        $account->data['MYMODULE_login_count'] = 1;
        user_save($account);
      }
    }
  }
}

/**
 * Implements hook_init().
 *
 * Here we set a JS settings variable according to whether our $account->data['MYMODULE_login_count'] created in MYMODULE_user_update
 */
function MYMODULE_init() {
  $alias = variable_get('mixpanel_alias', MIXPANEL_ALIAS);
  $js_settings = array(
    'create_user' => 0,
  );
  if ($alias != '_none') {
    global $user;
    $account = $user;
    if (isset($account->data['mymodule_login_count'])) {
      if ($account->data[mymodule_login_count'] == 1) {
        $js_settings = array('create_user' => 1);
        unset($account->data['mymodule_login_count']);
        user_save($account);
      }
    }
  }
  // We set the scope to JS_THEME so that it runs after mixpanel.js
  drupal_add_js(array('mymodule' => $js_settings), array('type' => 'setting', 'scope' => JS_THEME));
  drupal_add_js(drupal_get_path('module', mymodule') . '/mymodule.js');
}

Then we can fire off our event in the mymodule.js:

(function ($) {
  Drupal.behaviors.mymodule = {
    attach: function (context, settings) {

      // Send out user created event, which gets lost because of aliasing
      if (settings.mymodule.create_user) {
        mixpanel.track('user created');
      }
    }
  };
})(jQuery);

No activity for many years and Drupal 7 is now out of support. Marking out of date.