Tracking Embed Usage with a Correct User Count
Situation
When customers use embedded analytics, their users will often need multiple embed user IDs to access different data sets with different permissions. An example would be when a person works with different companies, so they need different sets of permissions to access each company’s data.
You can do this by giving a person several external user IDs, each with the right permissions for a particular data set. For example, if you had multiple doctors who each worked with several practices (companies), the external_user_ids could be:
DrZhang@app.com/Practice-A
DrZhang@app.com/Practice-B
DrGray@app.com/Practice-B
DrGray@app.com/Practice-C
Picking a Naming Convention for Tracking Usage
By default, each user ID is treated as a unique user. If you want to track a specific person's total usage, you’ll want a way to merge the usage for all of their IDs. An easy solution is to use a consistent naming convention for the external_user_id script parameter.
In the example above, the naming convention is actual-end-user-identifier/some-additional-context-needed-for-session-permission, where actual-end-user-identifier can be the person's email address and some-additional-context-needed-for-session-permission helps determine the permissions and what data this user ID should have access to.
This pattern identifies each unique person at the beginning. Now you can create an i__looker query with a custom dimension that returns the part of the ID that uniquely identifies the person. For example, DrGray@app.com/ uniquely identifies Dr Gray’s two user IDs. To get the ids grouped together, we needed to strip off anything after the / in embed_user.external_user_id.
Querying Usage
Querying by the custom dimension instead of the full external user ID will merge all of the person’s usage. In the example above, Dr. Gray’s two external user IDs will be grouped together as “DrGray@app.com/”.
From here you can audit usage by person, without counting a person multiple times. In the link below, replace hostname with your Looker hostname and run this query:
If your account representative requests an audit, you can create this query and schedule it to be sent to them. Alternatively, you can allow Looker to authenticate in to your instance, then your account representative can create and run the query.