Customer.io Cloud Mode Integration

After you have successfully instrumented Customer.io as a destination in RudderStack, follow this guide to correctly send your events to Customer.io in cloud mode.

Find the open source transformer code for this destination in the GitHub repository.

Identify

The identify event lets you identify a visiting user and associate them to their actions. It also lets you record the traits about them like their name, email address, etc.

userId is a mandatory field for sending identify events to Customer.io.

• API Version v1: If userId is absent, RudderStack uses the email field instead. If email is absent too, RudderStack drops the event.
• API Version v2 (default): Events without a userId fail. There is no fallback to email. The destination sends userId as the identifier you chose in userId Identifier Type.

RudderStack sends the createdAt field (mapped to Customer.io’s created_at property) to register the user signup time. If it is absent in the event, RudderStack automatically assigns the event’s timestamp to created_at before sending it to Customer.io.

A sample identify call is shown below:

rudderanalytics.identify("userId", {
  name: "Tintin",
  city: "Brussels",
  country: "Belgium",
  email: "tintin@herge.com"
});

Note that:

• You cannot use the same email to make consecutive identify calls with different userId fields.
• To update user information, you can use the Customer.io canonical identifier cio_id, as shown:

rudderanalytics.identify('<cio_id>', {
  email: '<updated_email>@example.com',
  id: '<updated_id>'
});

If API Version is v2, set userId Identifier Type to CIO ID so the destination sends this value as a cio_id.

Unsubscribe users

You can pass unsubscribed: true in the identify call to unsubscribe a user in Customer.io:

rudderanalytics.identify("27340af5c8819", {
  email: "alex@example.com",
  unsubscribed: true
});

Make sure the user ID and the email values match the Customer.io attributes. You can verify this by selecting that user in the People page in your Customer.io dashboard and clicking Attributes.

Track

The track event lets you record the user actions along with their associated properties and send them to Customer.io.

userId is a mandatory field for sending track events to Customer.io.

• API Version v1: If userId is absent, RudderStack uses the anonymousId field instead.
• API Version v2 (default): Events without a userId fail. There is no fallback to anonymousId.

A sample track call is shown below:

rudderanalytics.track("Track me", {
  category: "category",
  label: "label",
  value: "value",
});

For anonymous users, Customer.io does not permit an event name of size more than 100 Bytes. RudderStack automatically trims the event name in such a scenario.

See the Customer.io documentation for more information on the Track API event limits.

Page

You can use the page event to record the page views along with the other page-related information.

A sample page call is as shown below:

// "Home" is the page name.
rudderanalytics.page("Home", {
  path: "path",
  url: "url",
  title: "title",
  search: "search",
  referrer: "referrer",
});

Screen

The screen event is the mobile equivalent of the page event and lets you record the screen views on your mobile app along with other relevant information about the viewed screen.

If you have enabled screen views in your app implementation in the iOS (Obj-C) or Android (Java) SDK, RudderStack registers the screen views as Viewed <screen_name> Screen in the user’s Activities tab.

RudderStack also forwards the event properties to Customer.io as received.

A sample screen call using RudderStack’s iOS (Obj-C) SDK is shown below:

[[RudderClient sharedInstance] screen:@"Main"
            properties:@{@"prop_key" : @"prop_value"}];

RudderStack transforms the above event as Viewed Main Screen before sending it to Customer.io.

Group

Use the group call to link an identified user with a group like a company, organization, or an account. Group traits describe the Customer.io object, while traits.relationshipAttributes describes the relationship between the identified person and that object.

A sample group call is shown below:

rudderanalytics.group("acct-123", {
  name: "Acme Corp",
  relationshipAttributes: {
    is_admin: true,
    position: "account manager"
  }
});

RudderStack automatically maps the following properties to the corresponding Customer.io properties:

Note that:

• relationshipAttributes is supported for cloud-mode group calls when traits.action is identify (the default) or add_relationships. It is not supported for RudderStack identify calls.
• For API v1, the event can resolve the person from userId, context.traits.email, properties.email, or context.externalId.0.id. For API v2, the event requires userId and maps it according to the configured userId Identifier Type. If the event doesn’t resolve a person, RudderStack silently drops relationshipAttributes because there is no relationship to update.
• relationshipAttributes must be a nonempty object. RudderStack silently drops strings, numbers, arrays, and empty objects. It also excludes relationshipAttributes from the object’s own attributes — all other group traits continue to map to the object attributes.

Alias

The alias event lets you merge different identities of a known user. It is an advanced method that lets you change the tracked user’s ID explicitly.

The alias call is applicable only when both the user identities are present in Customer.io.

The mapping can be any one of the following:

• ID to ID
• email to email
• email to ID
• ID to email

A sample alias call is as shown below:

rudderanalytics.alias("userId", "previousId");

You can also merge two accounts via the user’s email address . RudderStack sets the primary email as userId and secondary email as previousId.

A sample alias call merging two accounts using the email address is shown:

rudderanalytics.alias("<primary.email>", "<secondary.email>");

Device token registration

RudderStack registers the device token to Customer.io for the below Application Lifecycle Events:

• Application Installed
• Application Opened

Enable the trackApplicationLifecycleEvents feature in your mobile SDK implementation code to use this feature.

Also, you need to register your device token after initializing the SDK. The following snippets demonstrate registering the device token for iOS and Android:

[[[RudderClient sharedInstance] getContext] putDeviceToken:[self getDeviceToken]];

RudderClient.putDeviceToken(getDeviceToken())

You can also specify the event name to be fired after setting the device token using the Event sent after setting device token dashboard setting.

Make sure to fire the event just after setting the device token in your app, so RudderStack can immediately register the device token to Customer.io and not delay until the next lifecycle event.

The following snippets highlight how to send a device_token_registered event after setting the device token in your app:

[[RSClient sharedInstance] track:@"device_token_registered"];

rudderClient!!.track("device_token_registered")

RudderStack also supports removing the device (identified by device_id) whenever you send a custom Application Uninstalled event.