Transcript

In this video, we’ll review the Totango In-App code snippet, which must be installed to publish in-app experiences. We recommend starting this process as soon as possible.

Objectives include, reviewing code snippet properties, adding and testing snippet on your website or application, and reviewing optional add-ons.

The builder code snippet not only allows you to publish experiences from Totango TO your web application, but it also gathers and sends account and user activity data back to Totango so that you can further track and segment users based on their interactions with In-App experiences.

To install the code snippet, you’ll need backend access to the website or application you’re deploying experiences on top of. Oftentimes, this step involves someone within your engineering team.

There are two installation scenarios to consider:

1. If your Totango instance is already collecting usage data via Totango’s JavaScript collector, your job will be very easy. If you’re unsure, you can go into Admin Settings > Data Management > Customer Data Hub. Look for Product Instrumentation. If you see a live session log on the right, and your data collection status is “Active,” this means you already have the required script installed and will only need your engineer to make a small tweak to the JavaScript version.
2. If you don’t have the JavaScript Collector script installed, you can back out of product instrumentation and go directly to Builder Settings. You can find the builder code snippet in your in-app builder, a link to which is included in the documentation. Items denoted in green are examples of what your engineering team would replace with values or variables from your own application.

Stick with me here because you likely have important “Totango” context for your engineer, even if you aren’t familiar with web development. The first thing you’ll need is your Totango Service ID, which you can find in Totango when you click on your profile menu. Copy everything starting with SP until the final digit. The next items are the user and account objects. What we’re doing here is telling the system to pass user and account information from your application to Totango. In other words, when a user of your system visits your application, we want Totango to either create a new account and user record for them (if they don’t already exist) or be able to match that person with existing records. As you may remember, Totango users cannot exist without an associated account record, so both are required.

Let’s look at the user object. The id that you’ll use in your script is likely not going to be a hard-coded id like john@anonymous.com. Instead, instruct your engineer to choose the variable within your web application that refers to a unique identifier for a user–making sure that identifier is also what you use in Totango for user ID. For example, if your application identifies user records by a unique string (let’s say 12345), but in Totango your user ID is email address (kitty@mycompany.com), you don’t want to use myuserobject.id here. Instead, your engineer would use a variable that maps to the user’s email (let’s say myuserobject.email). You can continue adding fields here, as available, for any additional information about the user record you want to bring over into Totango–these will also likely be variables.

The same applies to your account object. The variable you’ll likely use to identify an account object must represent the same type of identifier you use in Totango for account ID. In this example, the account ID in Totango is a unique string of 5 characters. If my application uses something different (like a Salesforce ID)...or doesn’t track account identifier at all–I should stop here and not install the script. Mapping an account identifier in both systems is required, so do not proceed. Please reach out to your Totango representative to discuss your options.

If you have the right identifier chosen, you can again add as many fields as you want to map to account attributes in Totango. “Status” may be a good example of a value that could be hard-coded as a constant in the script vs. using a variable. Once you have your code prepared, ask your engineering team to paste this code on every page of your application, just before the closing head tag. But remember, as soon as you do this, Totango will start collecting account and user data for any activity on your site and attempting to match existing records OR create new ones.

If you’re unsure, you may ask your engineer to enter a dummy service_id value “SP-XXXXXX-01” first, so that you can confirm. One trick I often use is to log into my application as different users. For each session, I open Chrome developer tools and add Watch variables for each user and account object so that I can see that the site is referencing the values I do indeed want to pass into Totango.

Once the code has been added, the install page will update with a list of your domains where the code is active. Totango also allows you to extend tracking, in two ways.

The first is the totango.identify method, which allows you to identify user attributes change throughout a user’s session on the website and leverage those conditions within your in-app experiences in real-time. These events don't necessarily require you to additionally track them in Totango as custom user attributes.

The second is for custom events, which allow you to enhance web application usage data within Totango—not just specific to in-app. These events tell Totango when a user does a specific action of importance on your application—such as updating their profile picture or sharing a document. You then leverage this usage data throughout Totango, including launching campaigns, SuccessPlays, and in-app experiences based on these events. Please note, these custom tracking events are different than the built-in in-app filters you can automatically leverage simply by installing the required script. You can learn more about those in other videos, and you can always come back and add the optional tracking info later.