Customer.io Device 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 device mode.

Add Customer.io integration

Make sure to add the Customer.io integration to your project before sending events to Customer.io in device mode.

Depending on your integration platform, follow these steps :

pod 'Rudder-CustomerIO', '~> 1.1.0'

RudderConfigBuilder *builder = [[RudderConfigBuilder alloc] init];
[builder withDataPlaneUrl:<DATA_PLANE_URL>];
[builder withFactory:[RudderCustomerIOFactory instance]];
[RudderClient getInstance:<WRITE_KEY>; config:[builder build]];

implementation 'com.rudderstack.android.sdk:core:[1.0,2.0)'
implementation 'com.rudderstack.android.integration:customerio:1.0.1'

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />

// initialize Rudder SDK
val rudderClient: RudderClient =
    RudderClient.getInstance(
        this,
        WRITE_KEY,
        RudderConfig.Builder()
            .withDataPlaneUrl(DATA_PLANE_URL)
            .withFactory(CustomerIOIntegrationFactory.FACTORY)
            .build()
    )

Web SDK version

For a web source connected in device mode, you can use the Web SDK Version setting to select the Customer.io client that the RudderStack JavaScript SDK loads. This setting is scoped to the web source connection.

New and existing destinations currently use v1 unless you explicitly select v2. If the version is missing or invalid, the integration uses v1.

On v2, RudderStack calls cioanalytics.setAnonymousId with the RudderStack anonymousId before it sends any event. The v2 client requires a non-empty Data Pipelines Write Key. If the write key is empty, the destination fails to load and reports an error.

Migrate to v2

To migrate a web device mode connection:

1. In Customer.io, create a Data Pipelines JavaScript source.
2. Connect the source to your Journeys workspace.
3. Set Web SDK Version to v2 for the web source connection.
4. Copy the source’s write key into Data Pipelines Write Key in the RudderStack destination settings.
5. Keep Site ID and API key populated if any cloud mode or mobile device mode source uses this destination.
6. To show in-app messages to unidentified visitors, enable Enable in-app messages for anonymous users and confirm the anonymous in-app message prerequisites.

Note that:

• On v2, web events land in the Data Pipelines source instead of going directly to Journeys. If you don’t connect the source to your Journeys workspace in step 2, the web events don’t reach Journeys.
• Anonymous in-app messages require a qualifying Customer.io plan. Cloud mode and mobile device mode are unchanged by the Web SDK Version setting. In-app messages are rendered by the browser SDK and can’t be delivered through cloud mode.

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 Customer.io. RudderStack drops the event if it is absent.

For web device mode, v1 sends identify({ id, ...traits }) to the Customer.io client, while v2 sends identify(userId, traits). The userId requirement is the same for both versions, and the createdAt to created_at mapping remains unchanged.

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>'
});

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.

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

In web device mode, page-view behavior depends on the selected Web SDK Version. The v1 integration loads the legacy Customer.io JavaScript snippet, which captures page views automatically. The v2 integration does not capture page views automatically — RudderStack page events drive them instead.

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

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

The group event lets you link an identified user with a group like a company, organization, or an account. It also lets you record any custom traits or properties associated with that group and send this information to Customer.io.

A sample group call is shown below:

rudderanalytics.group("group@49", {
  email: "help@rudderstack.com",
  action: "identify"
})

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

Alias

The aliasevent 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.