Natero

Introduction

Integrating customer data from third-party systems starts with a logical mapping between your accounts and users across systems.

Accounts and Users

The central entities within Natero are:

• Accounts: your customer accounts, typically companies.


• Account Users: your customer account users, typically people.

Natero Accounts have the following ID fields

Natero Account Users have the following ID fields

All roads must lead to account_id

As depicted above, account_id is Natero's alias for your unique customer IDs within your product. It is the ID that Natero expects to see in all product usage data (as well as user_id).

In order for Natero to perform its magic, all roads need to lead to account_id. This enables aggregation and account-based metrics to be calculated correctly.

Here is what a typical schema looks like:

Overcoming obstacles

While the mapping described above may seem trivial, the typical problem lies in cross resolving account_id for all third party systems, consider this example:

You have a customer named ‘ACME Services’, and this is what can be found in your product’s database:

{
 name: ‘ACME Services’,
 id: 34
 users: [ … ],
 ...
 }

You use a third party CRM system, and this customer can be found as follows in the Account table:

{
 Name: ‘ACME’,
 Id: 110
 ...
 }

Finally, you use a third party support ticket system and a similar record can be found in the organizations table:

{
 name: ‘Acme Inc.’,
 id: 2101
 ...
 }

In a world where data has been normalized to total cleanliness, it would be trivial to cross reference these records based just on name, website, domain, main contact email, phone number or some other attribute. The problem is that we live in the real world, and in the real world, data is not totally clean — it is common for company names to be misspelled, duplicate records to exist, etc

Unless an id-level mapping is provided for these records, it will be difficult to link them.

There are several options to resolve this situation:

Solution #1: add external IDs everywhere

Most third party systems allow you to add an external id either as a custom or canned field, it would be natural to use your own product account ID’s for those fields.

In our example, we added a custom field named ‘MyId’ to the CRM’s Account table:

{
 Name: ‘ACME’,
 Id: 110,
 MyId: 34
 ...
 }

And we populated the support system’s canned external_id field:

{
 name: ‘Acme Inc.’,
 id: 2101,
 external_id: 34
 ...
 }

Solution #2: place links in one or more 3rd party system

After having established the required mapping to your own product account_id for at least one of your third party systems, it is possible to take an indirect route for the other systems by using custom fields or plug-ins.

Some CRM systems, including salesforce, provide plug-ins for other third party systems, such as Zendesk for example.

These plug-ins will create the mapping we need in the CRM's Account table, we now have in the CRM:

{
 Name: ‘ACME’,
 Id: 110,
 MyId: 34,
 Support__Id: 2101
 ...
 }

Note the new Support__Id field.

Support System is unchanged:

{
 name: ‘Acme Inc.’,
 id: 2101
 ...
 }

Solution #3: map it with Natero’s API

Another option is to use Natero’s customer facing Account API to provide the mapping as follows:

{
 account_id: 34
 crm_account_id: 110,
 support_account_Id: 2101
 ...
 }

We have now learned how to cross resolve account_id for all third party systems!

Mapping users to accounts

Once you have established a path to account_id for all systems, please check that users are also mapped to their respective organizations within each system.

In CRM Systems

The correct association of Contacts with Accounts is crucial to avoid having incomplete Account User meta data, ie missing contact info such as email or phone number. This leads to being unable to take action on alerts within Natero.

For example, if you are using Saleforce, you can identify this problem by looking for missing or null AccountId within the Contact table.

In Support Ticketing Systems

It is quite common for users to register within your support system to submit tickets, without ever being associated with an organization. This situation leads to these tickets not being attributed to any organization, and could potentially mean the loss of customers which could have been detected much earlier as “at risk” by Natero.

For example, if you are using Zendesk, you can identify this issue by looking for Users with missing or null organization id. This link provides instruction on how to create and manage organizations within Zendesk.