Segment is a powerful platform for gathering customer data from different sources and distributing it to multiple destinations, such as Marketo, seamlessly. If you have bespoke data sources e.g. activities from your portal, that you cannot get into Marketo using the launchpoint service then the Segment CDP is your knight in shining armour!
This post will give you an introduction to the Segment platform covering these basics
If you want a recap on the definition of a CDP and how it is different from a marketing automation platform then check out my first post on this topic What is a CDP in Marketing?. Or if you want to get straight into the nitty-gritty then check out the Segment Marketo Integration post to see how to set up Marketo custom activites and fields.
On a separate note, have you checked out the Marketo API Crash Course yet? If you want hands-on video walkthroughs of how to get set up with the Marketo API and see real-life marketing operations use cases for the API then check out the course using the button below 🙂
Take Tyron’s Course on Demand
For a more in-depth look into each of these identity types you can take a look at the Segment Spec Overview.
Entering the “Sources” section will reveal all the incoming sources that are contributing data. Clicking into a particular source will reveal all the destinations that are receiving data from this source in the “Overview” tab. Within a source, two tabs that are useful for testing and insight are the “Debugger” and “Schema” tabs.
The “Debugger” allows you to see all the event types that are coming into Segment from this source, live, in real-time, with different filters and keyword search allowing you to narrow in on certain events.
Selecting a certain event from the Debugger stream will bring up the contents of that event in a pane on the right hand side. The contents of the event will be in JSON format with the “Pretty’ tab offering a filtered and condensed version of the event information from the “Raw” tab. If you want to edit the contents of this event payload then you will need to talk to the engineers that are responsible for sending this event to Segment from either the front or back end of your site.
In the “Raw” tab you can see the integrations section of the event payload that details all the destinations that will receive information from this event. You can explicitly set each destination to true or false as follows:
"integrations": {
"Destination 1": true,
"Destination 2": false,
"Destination 3": True
}Alternatively, you can use the “All” key to set the default for all sources and then list exceptions to the rule. In the example below this event will be sent to all destinations except for the Marketo destination.
"integrations": {
"All": true,
"Marketo V2": false
}Finally, if you want to test sending this event to a particular destination then click on the “Validate” option in the top right-hand corner, which will allow you to select a destination and then bring you to the event tester for that destination. The “Event Tester” will already be populated with the exact contents from the event that you selected (see more in the “Segment Event Tester” section below)
The schema overview is useful for checking that Segment is receiving events as normal from the various different sources.
The graph at the top of the page shows the distribution of the total number of event calls day over day within the time period while the table below the graph shows the event count for all the different events within the time period.
Clicking into a particular event will reveal a day over day graph showing the distribution of this event over the time period, while the table below illustrates the number of time event properties were actually present in the event payload. For example, in the image above we see that over the 7 day period there were a total of 252,383 “Page Viewed” events but only the “path” and “url” properties were present in every single call.
If there are other event properties e.g. “referrer” and “search”, that are also meant to be present in every “Page View” event then you know that not all of the required information is being passed from the front or back end (front end in this case for a page view).
The “Event Tester” is a handy tool that allows you to send test events to your destination and see exactly what Segment is sending to the destination and the response the destination sends back.
There are two ways to create a test event. You can paste the JSON payload for the event (either Track, Identity, Page, Screen, or Group) in the window. Alternatively, you can use the “Event Builder” tab to build the event from scratch by filling out the event type, name, and properties as well as the user id that the test event is being sent on behalf of.
As mentioned in the “Segment Source Debugger” section above, if you are in the “Debugger” for a source and you click into an event, then you can send this event to the “Event Tester” of a destination using the “Validate” option in the top right-hand corner.
Once you press “Send Event” then the “Event Lifecycle” field will populate on the right-hand side of the screen. There is a number in the top right-hand corner that shows how many request-response interactions there were along with arrow keys to page through these different interactions. Within a particular interaction, you can use the “Request from Segment” tab to see the JSON payload of what Segment sent to the destination. The “Response from Destination” tab then shows the JSON payload the destination sent back indicating whether the request was successful.
The first request that Segment will always make is to get the Marketo lead id of the person who carried out the event. Segment will lookup the lead id using the email address if it is present (as shown below) or it if the email address is not present it can also use a custom id field to lookup the lead in Marketo.
Once Segment has obtained the Marketo lead id it then sends a request to the external activities endpoint specifying this lead id along with the primary key value for the Marketo custom activity and any other event properties that have been mapped to custom activity fields (see the Marketo Custom Activities section in the “Segment Marketo Integration” post)
The “Event Delivery” section is useful for checking that events sent to this destination are going through successfully.
The time period for the “Delivery Summary”, “Delivery Trends”, and “Delivery Issues” can be adjusted from 10 minutes to the past 2 weeks. The “Delivery Summary” is useful for getting a snapshot view of average performance over the time period while the “Delivery Trends” graph allows you to dig further and see the times when errors are most prevalent or when latency is highest.
Clicking into a particular delivery issue will bring up a pane on the right-hand side of the screen, which will show up to 20 examples of the sent-request-response interactions related to the delivery error.
A lot of the errors you will see are out of your control. They are due to Segment not adhering to Marketo’s REST API limits and protocols e.g. the 6XX errors below, or system issues between Segment and Marketo e.g. the non 6xx errors below. All of the errors below are usually temporary meaning when Segment later retries sending the event it should go through successfully.
Instead, focus on error codes that you do have the power to fix e.g. 1XXX or “Message Rejected”. The “Message Rejected” error for example occurs because there is an event being sent to Marketo that has not been mapped to a custom activity or does not include all of the required properties e.g. the primary key (see the Marketo Custom Activities section in the “Segment Marketo Integration” post)
You can use the “Event Tester” described above to test out potential fixes and see if the event goes through to the destination successfully.
Now that you have taken a look under the hood and you know how Segment receives, handles, and distributes the data it receives, it is time to setup Marketo custom activities and fields so that you can get this juicy info into Marketo!
Greetings fellow MO Pros! As a previous mechanical engineer turned marketing operations lead, I now fancy myself as a full-stack marketer capable of designing websites, writing SEO-optimized content, and doing all the tracking and automation on the backend. That being said my bread and butter is marketing operations and I love to get down and dirty with the Marketo API, Python, Zapier, and Google Scripts.
Created with the assistance of DALL·E Introduction and Background In 2018, Edward Unthank introduced the four pillars of marketing operations, setting the stage for the management of effective marketing technology (Martech) functions. These pillars have since been the bedrock for many successful careers in marketing operations. My journey to redefine
Introduction When it comes to account-based marketing (ABM), your marketing team might have invested in intent data, built tailored content, and spent time targeting accounts. But is the juice worth the squeeze? You could say marketing operations teams are there in part to squeeze every last marketing dollar in order
Introduction: Blending Human and Technical Perspectives in Martech Caption: Future gardens of martech will blend human and AI perspectives As a co-host of the Humans of Martech podcast, I’ve had the privilege of interviewing some of the brightest minds in marketing technology. This unique experience has provided a blend of
Subscribe to our newsletter!
