10

Destinations overview

How it works

A destination is the place you want to send your data to, like analytics platforms, CRMs, support tools, advertising platforms, messaging platforms, and more. We reshape data from your sources to fit the shapes expected by your destination, so you can use your source data in any available destination.

Depending on your source, data travels from your source through Customer.io to your destination or directly to your destination.

• Cloud connection: data travels from your source to Customer.io and then to your destination.
• Direct connection: data travels directly from your source to the destination. Direct connection destinations are limited to our Website source and are sometimes called “web” destinations.
• Data warehouse destinations are a specialized type of cloud connection, where source data goes through Customer.io, where we transform the data and send it in batches to tables in your database. See our data warehouse destinations for more information.

Set up a Destination

The steps involved in configuring your destination will change based on the specific destination and mode you enable. See an individual destination to learn more about the individual steps, and the information you’ll need, to connect a destination.

1. Go to the Data Pipelines tab and click Connections.
2. Click Add New under Destinations.
3. Select the Destination you want.
4. Configure your destination and click Continue.
5. Select the mappings—the actions that you want to send to the destination. See Subscriptions below for more information.

    You can change field mappings

   In most cases, you’ll want to use default mappings with your destination. But, if you have a specialized use case and want to change the way we map fields to your destination’s events. See Mapping below for more information.

6. (Optional) Select the sources that you want to connect to this destination. You can always connect sources to your destination later. You may not want to map sources to your destination
7. Click Enable Destination.

You can check the Actions tab to see data as it comes in. This helps you make sure that your destination is set up correctly.

Actions

Your destination’s Actions tab shows recent data sent to the destination. You can find specific actions and look at the data as it’s sent to your destination. You might use this to troubleshoot specific source events.

When you set up a destination, you can check Actions to change the way we map source data to your destination—or just to better understand what data we’ll send to your destination by default.

Mapping source calls to your destination

Most destinations support Actions. Actions are how we map data from sources to your destination—the “trigger” for each request, and the fields we map to your destination.

In most cases, you’ll want to stick with the defaults. But, you might disable actions that you don’t care about in your destination. Or you might click and select Edit to change the way we map data to an action—this can help you better represent your model data in your destination if our default mappings don’t quite match your use case.

See our actions guide for more information.

API Call tester

On the API Call Tester tab, you can send calls to your destination to make sure that your integration works the way you expect. It may help to run test calls before you connect a source to your destination—so it’s easier to find your tests.

API calls are formatted to fit our source API. This gives you an opportunity to see how a call from your source(s) maps to your destination.

Test calls are populated with test data. Use the dropdown to select the kind of call you want to test.

Destination Overview

The destination Overview tab shows action volume and how many actions were completed or failed over a time frame. The overview helps you understand if your integration works as you expect, and can help you spot performance issues—failed actions or high latency.

Choosing a connection mode

When you add a destination, you may see mode options. We offer destinations in cloud mode and direct mode—also known as web destinations. The “mode” determines how we send data to your destination—through Customer.io’s servers or directly from your source. The major differences are that:

1. Direct mode only supports web (JavaScript) sources.
2. Cloud mode calls go through Customer.io servers; direct mode calls go directly to your destination, bypassing Customer.io.

In most cases, you should use cloud mode. You should use cloud mode unless you have a specific reason to use direct mode. Cloud mode supports more sources, provides an easily-accessible record of calls in Customer.io so it’s easier to trace and debug calls all the way from source to destination.

Cloud Mode

In Cloud Mode your source sends data to our servers, which transform and forward data to your downstream destinations. This keeps the size of injected scripts in your source(s) small and load times fast. Most importantly: this mode ensures that we keep a record of data sent to your destination, which can help you audit and troubleshoot issues with your destination.

Direct Mode

In Direct Mode, your destination expects to receive data directly from your source without going through Customer.io’s servers. You might use this mode if your sources need to be loaded directly on a device or in a webpage. Because Direct Mode destinations don’t send data to Data Pipelines servers, you won’t see a record of actions sent to your destination.

This can make it tricky to debug direct-mode destinations. If you need to debug or troubleshoot direct-mode destinations, you can try observing network calls in your browser console. If you need Customer.io’s help to troubleshoot direct-mode destinations, you may need to provide us with access to a staging environment where we can observe your integration.

In general, you probably only need to use direct mode if:

• Direct mode is required by your destination. Some destinations only support direct mode.
• You rely on destination features that require direct access to a service—like if you use Adobe Target and you want to load Adobe Target’s SDK (at.js) to take advantage of their A/B testing and personalization features.
• You need to minimize latency between your site and your destination. For example, if you use a live chat destination, you might want to use direct mode to ensure that your events pass to your live chat service as quickly as possible.

If you use our JavaScript source, we’ll automatically translate data for your various cloud or direct-mode destinations so you don’t need to write any code. You don’t need to use the same mode for all destinations in a workspace; some can use device-mode, and some can use cloud-mode.

How do I tell which modes are supported by a destination?

Luckily, there are a few ways to do this. If you’re looking at the destination catalog in our docs, you’ll see icons for cloud mode () and direct mode ().

Retries: how we handle outages

If your destination suffers an outage, we’ll retry sending to the destination. We retry up to 14 times with an exponentially increasing delay between retries. The maximum retry window is about three hours.

We don’t retry when we get a definitive error, like a 400 or 403. Rather, we retry in the following situations:

• 429s: we’ve exceeded the destination API’s rate limit
• 5xx: the destination reported internal error
• Network errors: we were unable to establish network connection with the destination
• Other errors: errors that don’t produce status codes or are otherwise unrecognized

If you encounter errors and change your destination’s settings, or action settings for the destination, we’ll use the correct settings on the next retry. This makes it easy to fix problematic settings in your destination’s setup.