Skip to content

Commit 72e41ca

Browse files
stayseesongstayseesong
committed
updates
1 parent b7bd2a2 commit 72e41ca

File tree

1 file changed

+57
-108
lines changed

1 file changed

+57
-108
lines changed

‎src/connections/destinations/index.md

Lines changed: 57 additions & 108 deletions
Original file line numberDiff line numberDiff line change
@@ -2,20 +2,15 @@
22
title: Destinations Overview
33
---
44

5-
Destinations receive data from Segment.
6-
7-
If you want to explore the destinations compatible with Segment, check out the [Destinations catalog](/docs/connections/destinations/catalog/). Select an item from the catalog to learn more about it. The documentation for each destination explains how the Segment Tracking API methods are implemented for that destination.
5+
Destinations are the business tools or apps that Segment forwards your data to. Adding Destinations allow you to act on your data and learn more about your customers in real time.
86

7+
> info "Destinations Catalog"
8+
> If you want to explore the destinations compatible with Segment, check out the [Destinations catalog](/docs/connections/destinations/catalog/). Select an item from the catalog to learn more about it. The documentation for each destination explains how the Segment Tracking API methods are implemented for that destination.
99
1010
## Sources vs Destinations
1111

1212
Segment has [Sources](/docs/connections/sources/) and [Destinations](/docs/connections/destinations/). Sources send data _into_ Segment, while Destinations receive data _from_ Segment.
1313

14-
### Types of sources
15-
16-
Segment has five types of sources: Web (Analytics.js), Mobile, Server, Cloud App, and User-created [Source Functions](/docs/connections/sources/source-functions/). Web, Mobile, and Server sources send first-party data from your digital properties. Cloud-app sources send data about your users from your connected web apps, such as [Zendesk](/docs/connections/sources/catalog/cloud-apps/zendesk/), [Stripe](/docs/connections/sources/catalog/cloud-apps/stripe/), or [Braze](/docs/connections/sources/catalog/cloud-apps/braze/).
17-
18-
1914
## Method compatibility
2015

2116
Not all destinations can accept data from specific method types. To know if a destination can accept data from specific method types, look for the *Quick Info* box at the top of the destination's documentation page, or check out the [Destinations Methods comparison chart](/docs/connections/destinations/methods-compare/).
@@ -36,6 +31,32 @@ In June 2021, Segment released a new form of destinations called [Destinations A
3631
{% include content/connection-modes-intro.md %}
3732

3833

34+
### Choosing a connection mode
35+
36+
Cloud-mode destinations send data through Segment. Device-mode destinations send data in parallel to Segment. There are tradeoffs between using cloud-mode and device-mode destinations. In general, Cloud-mode is preferred because you then benefit from Segment's system features, like retries, Replay, Warehouses, Privacy blocking, filtering, and more.
37+
38+
You should consider using device-mode if you use destinations which record information directly on the user's device. These types of tools might lose functionality if they aren't loaded directly on the device.
39+
40+
Take a look at the pros and cons chart of device-mode and cloud-mode destinations to determine which connection mode is best for you:
41+
42+
Connection Mode| Pros | Cons |
43+
-------------- | ---- | ---- |
44+
Cloud-mode | * Increased site or app performance<br>* Unaffected by ad blockers | * May limit Destination features |
45+
Device-mode | * Access to all features of the Destination | * Decreased site or app performance |
46+
47+
#### Website source connection modes
48+
49+
Segment's website sources use device-mode by default, because so many website-based destinations require that they be loaded on the page, and because size and page performance are less of a concern than on mobile. If your website source only collects information that you can instrument yourself, then you can use cloud-mode.
50+
51+
For example, a web-chat destination must be loaded to connect to the service and collect metrics efficiently - you don't expect it to route chat messages through Segment! This _does_ mean that Segment might not receive a small amount of the destination-specific information from your users. In the chat example, if the destination is calculating idle time between messages, that data would appear in the destination's tooling, but not necessarily in the Segment data.
52+
53+
#### Mobile source connection modes
54+
55+
By default, destinations configured on a mobile source send their data directly to the Segment servers, then translate it and use Cloud-mode to forward it to destinations. *Cloud-mode* means that Segment sends the data directly from the Segment servers, to their servers. This means you don't need to package third-party SDKs for destinations that can accept cloud-mode data. Some primarily web-based destinations also allow cloud-mode, which can help reduce app size, and improve load time and performance. You can read more about the [effects of mobile app size on downloads in Segment's blog](https://segment.com/blog/mobile-app-size-effect-on-downloads/).
56+
57+
Before you turn on or opt-in for cloud-mode for a mobile source, consider if your destinations have features that require interactions on the device or require device-specific data (see the examples above). For example, if you use cloud-mode for Mixpanel, you'll get your data on reporting and people, but won't be able to use their features for in-app surveys or auto-tracking. These can be really valuable, but might not be a priority for your team.
58+
59+
3960
### How Segment determines Device-mode and Cloud-mode destinations
4061

4162
There are two main things Segment considers when deciding to use Device-mode or Cloud-mode, or both, for a destination partner:
@@ -62,32 +83,26 @@ Many of Segment's destinations offer client-side features beyond data collection
6283

6384
Some features that usually require Device-mode include: automatic A/B testing, displaying user surveys, live chat or in-app notifications, touch and hover heatmapping, and accessing rich device data such as CPU usage, network data, or raised exceptions.
6485

65-
66-
### Choosing a connection mode
67-
68-
Cloud-mode destinations send data through Segment. Device-mode destinations send data in parallel to Segment. There are tradeoffs between using cloud-mode and device-mode destinations. In general, Cloud-mode is preferred because you then benefit from Segment's system features, like retries, Replay, Warehouses, Privacy blocking, filtering, and more.
69-
70-
You should consider using device-mode if you use destinations which record information directly on the user's device. These types of tools might lose functionality if they aren't loaded directly on the device.
71-
72-
#### Website source connection modes
73-
74-
Segment's website sources use a device-mode by default, because so many website-based destinations require that they be loaded on the page, and because size and page performance are less of a concern than on mobile. If your website source only collects information that you can instrument yourself, then you can use cloud-mode.
75-
76-
For example, a web-chat destination must be loaded to connect to the service and collect metrics efficiently - you don't expect it to route chat messages through Segment! This _does_ mean that Segment might not receive a small amount of the destination-specific information from your users. In the chat example, if the destination is calculating idle time between messages, that data would appear in the destination's tooling, but not necessarily in the Segment data.
77-
78-
#### Mobile source connection modes
79-
80-
By default, destinations configured on a mobile source send their data directly to the Segment servers, then translate it and use Cloud-mode to forward it to destinations. *Cloud-mode* means that Segment sends the data directly from the Segment servers, to their servers. This means you don't need to package third-party SDKs for destinations that can accept cloud-mode data. Some primarily web-based destinations also allow cloud-mode, which can help reduce app size, and improve load time and performance. You can read more about the [effects of mobile app size on downloads in Segment's blog](https://segment.com/blog/mobile-app-size-effect-on-downloads/).
81-
82-
Before you turn on or opt-in for Cloud-mode for a mobile source, consider if your destinations have features that require interactions on the device or require device-specific data (see the examples above). For example, if you use cloud-mode for Mixpanel, you'll get your data on reporting and people, but won't be able to use their features for in-app surveys or auto-tracking. These can be really valuable, but might not be a priority for your team.
83-
84-
8586
### How can I tell which connection modes and platforms are supported for a destination?
8687

8788
The first place to look is the individual destination documentation. Each one includes a matrix of supported Sources and Connection Modes. Segment provides a list of [all destinations and their connection modes](/docs/connections/destinations/cmodes-compare/).
8889

8990
In order to override the default, check the destination settings pane in the Segment web App either for a **Connection Mode** toggle or instructions on bundling any additional mobile components required.
9091

92+
## Add a destination
93+
To add a Destination:
94+
95+
1. Navigate to **Connections**.
96+
2. Click **Add Destination**.
97+
3. Choose the Destination you want to add and click **Configure**. Most users eventually add destinations for: Analytics, Advertising, Email Marketing and/or Live Chat.
98+
4. Select the Source you want to connect to your Destination.
99+
5. Click **Next**.
100+
6. Give you Destination a name.
101+
7. Click **Save**.
102+
8. Configure the settings and enable your destination on the destination settings page.
103+
104+
[Learn more](/docs/connections/destinations/add-destination/) about what adding a destination entails.
105+
91106
## Data deliverability
92107

93108
Segment increases deliverability to destinations in two ways: [retries](#retries) and [replays](/docs/guides/what-is-replay/). Retries happen automatically for all customers, while replays are available on request for [Business](https://segment.com/pricing/) customers.
@@ -102,93 +117,27 @@ When you use Segment's mobile SDK, Segment dispatches each event to a background
102117

103118
If the delivery of the payload is not successfully sent due to connection issues, all of your SDKs will automatically retry the request until successful receipt of the payload according to the following policies. Note that retry policies are subject to change / tuning in the future.
104119

105-
<table>
106-
<tr>
107-
<td>Platform</td>
108-
<td><b>Initial Wait - </b>Sleep duration before the first retry</td>
109-
<td><b>Wait Growth - </b>Rate of growth of the sleep duration between each retry</td>
110-
<td><b>Max Wait - </b>Maximum sleep duration between retries</td>
111-
<td><b>Max Attempts - </b>Maximum number of individual retries</td>
112-
</tr>
113-
<tr>
114-
<td>**C++**</td>
115-
<td>1s</td>
116-
<td>None</td>
117-
<td>1s</td>
118-
<td>5</td>
119-
</tr>
120-
<tr>
121-
<td>**Clojure**</td>
122-
<td>15s</td>
123-
<td>Exponential</td>
124-
<td>1h</td>
125-
<td>50</td>
126-
</tr>
127-
<tr>
128-
<td>**Go**</td>
129-
<td>100ms</td>
130-
<td>Exponential</td>
131-
<td>10s</td>
132-
<td>10</td>
133-
</tr>
134-
<tr>
135-
<td>**Java**</td>
136-
<td>15s</td>
137-
<td>Exponential</td>
138-
<td>1h</td>
139-
<td>50</td>
140-
</tr>
141-
<tr>
142-
<td>**JavaScript**</td>
143-
<td>1s</td>
144-
<td>Exponential</td>
145-
<td>1h</td>
146-
<td>10</td>
147-
</tr>
148-
<tr>
149-
<td>**.Net**</td>
150-
<td>100ms</td>
151-
<td>Exponential</td>
152-
<td>6.4s</td>
153-
<td>7</td>
154-
</tr>
155-
<tr>
156-
<td>**Node.js**</td>
157-
<td>100ms</td>
158-
<td>Exponential</td>
159-
<td>400ms</td>
160-
<td>3</td>
161-
</tr>
162-
<tr>
163-
<td>**PHP**</td>
164-
<td>100ms</td>
165-
<td>Exponential</td>
166-
<td>6.4s</td>
167-
<td>7</td>
168-
</tr>
169-
<tr>
170-
<td>**Python**</td>
171-
<td>1s</td>
172-
<td>Exponential</td>
173-
<td>34m</td>
174-
<td>10</td>
175-
</tr>
176-
<tr>
177-
<td>**Ruby**</td>
178-
<td>100ms</td>
179-
<td>Exponential</td>
180-
<td>10s</td>
181-
<td>10</td>
182-
</tr>
183-
</table>
120+
Platform | **Initial Wait -** Sleep duration before the first retry | **Wait Growth -** Rate of growth of the sleep duration between each retry | **Max Wait -** Maximum sleep duration between retries | **Max Attempts -** Maximum number of individual retries
121+
-- | -- | -- | -- | -- |
122+
C++ | 1s | None | 1s | 5
123+
Clojure | 15s | Exponential | 1h | 50
124+
Go | 100ms | Exponential | 10s | 10
125+
Java | 15s | Exponential | 1h | 50
126+
JavaScript | 1s | Exponential | 1h | 10
127+
.Net | 100ms | Exponential | 6.4s | 7
128+
Node.js | 100ms | Exponential | 400ms | 3
129+
PHP | 100ms | Exponential | 6.4s | 7
130+
Python | 1s | Exponential | 34m | 10
131+
Ruby | 100ms | Exponential | 10s | 10
132+
184133

185134
#### Mobile library retries
186135

187136
All mobile libraries handle retries by periodically attempting to flush their internal queue of events to Segment. If the flush is unsuccessful, the library waits until the next regularly-scheduled flush time to try again. The background queue of requests to Segment is bounded in size so if events are being queued faster than we can successfully flush them to Segment, some events may be dropped.
188137

189138
#### Retries between Segment and destinations
190139

191-
The destination endpoint APIs we send data to have fluctuations in availability due to any number of issues ranging from network failures to bugs to overload. Segment's internal systems retry failed destination API calls for 4 hours with a randomize exponential backoff after each attempt. This substantially improves delivery rates.
140+
The destination endpoint APIs have fluctuations in availability due to a number of issues ranging from network failures to bugs to overload. Segment's internal systems retry failed destination API calls for 4 hours with a randomize exponential backoff after each attempt. This substantially improves delivery rates.
192141

193142
Here's an example destination that was only successfully accepting 93.36% of all API requests but was achieving a 99.28% final deliverability rate due to Segment's retry functionality.
194143

0 commit comments

Comments
 (0)