Excluding Admin Users in Customer Accounts

If you have Customer Service Reps or other employees placing or editing orders on behalf of your customers, then you need to take steps to prevent issues with Rockerbox's ability to attribute touchpoints back to your users.

What’s the Issue?

  • When admin users log into client accounts, the Rockerbox pixel fires like normal, including the Rockerbox cookie id and customer data associated with the account.
  • This means we’ll receive pixel fires with the admin’s cookie id + the customer’s external id and email
  • This ends up polluting our identity resolution as we now link the admin’s identity (their cookie id) with the user’s identity - to Rockerbox, it looks like the admin and the customer are the same person

What’s the End Impact?

  • When Rockerbox sees a link between two identifiers (such as the Rockerbox cookie id <> external id), we stitch those users together.
  • When we build our path-to-conversion, we look at all the marketing touchpoints associated with the conversion across all the stitched identities.
  • If admin users go into customer accounts, the admin’s marketing touchpoints will be incorrectly linked with the customer’s conversion unless we take steps to prevent it

How do I Prevent this Issue?

  • If you want Rockerbox to count the conversions placed by CSRs or employees (if they are placing real orders that you want to reconcile against your internal database, for example):
  • Add an “ignore_user_events: true” property to our pixel fires and we will not use the data from that pixel fire in our identity resolution or path-to-conversion, but we will count the conversion


RB.track("conv.purchase", { 
ignore_user_events: true,
email: "customer@gmail.com",
external_id: okl_customer_id_here,
// other regular stuff goes here

If you don’t want to count the orders placed by CSR’s (because they’re test orders, for example):

The right solution, in this case, is to not fire the Rockerbox pixel at all. To do this, you should add logic to your GTM or Segment implementation to prevent Rockerbox pixels from firing for internal users

Blocking Specific Customer Traffic from Appearing in Rockerbox Reporting

The first approach for ensuring that test or admin traffic does not appear in Rockerbox reporting is to block events from firing for these users.

If this is not an option, you can also exclude these users' attribution or order data from appearing in Rockerbox reporting.

To do this, there must be a common identifier that you will exclude within Rockerbox. Eligible fields to exclude users from include:

  • Excluded Domains
    • email address
    • domain
  • Excluded Customer Identifiers
    • uid
    • external id
    • ip address
    • phone number
    • segment anonymous id

How did we do?