Adding docs for Segment RETL destination #3911
Conversation
Going to make more edits, but committing these for now
|
Going to review tomorrow Thurs 12/8. Let's hold off on merging/deploying this until next Tues 12/13 please. Thanks! |
| @@ -33,4 +33,4 @@ The Segment destination enables you to mold data extracted from your warehouse i | |||
| ## FAQ & Troubleshooting | |||
|
|
|||
| ### API Calls and MTUs | |||
There was a problem hiding this comment.
I believe the plan is to only charge MTUs if the customer connects the source to a "classic" destination. If they only connect it to Engage then I don't think there would be any potential additional MTUs
There was a problem hiding this comment.
This is only once we build a separate Segment Profiles destination. Today, there's no way for the team to bypass additional API calls/MTUs when connected to Engage since the data still needs to pass through the front door (i.e. HTTP API source). This is why our team is building a separate Segment Profiles destination in Q1 that would ideally allow connecting to only Engage spaces and bypass additional MTU/API calls costs.
|
|
||
| {% include components/actions-fields.html %} | ||
| {% include components/actions-fields.html settings="true"%} | ||
|
|
||
| ## FAQ & Troubleshooting |
There was a problem hiding this comment.
It might be worth calling out that the "Send test record" feature sends live events to the source. So for example, let's say a customer sets everything up and has a "classic" destination configured. Then at a later time they add a new mapping . If they use the "Send test record" feature, that test will be sent to HTTP API source and subsequently sent downstream to any connected destinations.
There was a problem hiding this comment.
This is a good point, but it's true of all Actions destinations/testers so not sure we really need to call it out one-off in this doc.
There was a problem hiding this comment.
Maybe it's worth putting a note about that in these docs instead, if you want to file a separate PR for that: https://segment.com/docs/connections/destinations/actions/#customize-mappings
| 2. Click **Add Destination** in top-right corner. | ||
| 3. Select the Segment destination, click **Next**, and select the warehouse source that will send data to the Segment destination. If you have not set up a warehouse source, follow the steps in the Reverse ETL documentation on [Getting started](/docs/reverse-etl/#getting-started). | ||
| 4. On the **Settings** tab, name your destination, input the Write Key from the source created above, select an endpoint region, and click **Save Changes**. | ||
| 5. On the **Mappings** tab, click **Add Mapping**. Select a data model and the API call type you want to map. You can configure multiple mappings. |
There was a problem hiding this comment.
If we assume that the customer is connecting this to a new model, then at the moment (though this may change) once you enable everything, the initial sync will kickoff. After that, only net new records will be sent (as a result of subsequent syncs). Therefore, it might be best to recommend all of the desired mappings be configured before the destination is enabled.
Here is an example of how this issue could play out:
- Create a new model
- Create a mapping for a given method (e.g. identify)
- Enable that mapping
- Data syncs for the first time and reaches the debugger
- Then you create a new mapping for a different method (e.g. track)
- Enable that mapping
- No data will be sent to the debugger unless a new record is Added or Updated (because the new model has already synced)
There was a problem hiding this comment.
@James9446 sounds good. Can you make the suggested edit to reflect this?
Updated the steps for connecting and configuring the Segment destination. The goal of this doc update is to prevent customers from accidentally only sending a full sync to the first mapping created. It is therefore recommended to configure and enable all mappings before enabling the Segment destination.
|
Looks all set to me - thank you for your help James! |
|
Thank you for your contribution! Your pull request is merged, but may take a day or two to appear on the site. |
Proposed changes
Segment (Actions) are in private beta. We are moving to public beta on December 13.
Since this destination is in Private Beta, can we make sure that the dossier and other tables (other versions of destination, settings, actions, fields) get pre-populated upon deploy just in case the partner portal status hasn't updated in time? Thank you!
Merge timing
Related issues (optional)
new-integration