Plan for Send Logging
Learning Objectives
After completing this unit, you’ll be able to:
- Describe the purpose of send logging.
- Evaluate your send logging needs.
- Create a basic send logging plan.
Time to Capture the Data
Marketing Cloud Engagement offers a vast amount of information through Analytics Builder and its suite of standard reports. However, there are times you may need to collect more specific data—and take action on that data. That’s where send logging comes in! Send logging data extensions can capture information that standard reporting and tracking doesn’t, especially as it relates to a specific send and what material was included in the send. Send logging can capture things like:
- A single location of the JobID value and any other campaign or custom ID values you want
- The exact data included in the send, even if you use highly customized and personalized scripted content
- Any material or attribute values included in the send
All of this information can enhance marketing activities that require information only provided at send time—just keep in mind a few limitations.
- Send logging data extensions cannot retrieve send information retroactively.
- Modifying a send logging data extension after you create it can be difficult.
- Send logging data extensions can capture a lot of information as part of normal sending processes. Extremely large send logging data extensions can cause send delays and affect performance. Therefore, you need to plan your retention policies early.
In this module, we give you the tools you need to use send logging effectively and avoid slow sends, broken automations, and other pitfalls. One of the most important first steps is planning ahead—let’s get started!
Send Logging Data Extensions
First, let’s start with the send logging data extension. Marketing Cloud Engagement provides data extension templates for email, SMS, and push message sends that include some basic information. You can also add custom fields, such as the URL for View as a Web Page functionality or campaign data. Keep in mind that these data extensions involve a lot of data and processing, so you need to plan wisely to capture only what you need and ensure that multiple processes don’t try to use a data extension at the same time. Why? Because you can have only one send logging data extension per channel (email, SMS, and push) per MID (top-level account or business unit in your tenant). So make the most of the space you have.
Templates
Send logging data extensions always start with a template. By default, each template includes the following fields based on send type.
| Email Template | |
|---|---|
| JobID | The numeric identifier of a traditional email send |
| ListID | The unique identifier created by the application |
| BatchID | A unique identifier for a unit of work handled by the messaging service. Each batch contains one or more subscribers |
| SubID | The SubscriberID of each message recipient |
| TriggeredSendID | The unique identifier for the triggered send definition (only applies to triggered sends) |
| ErrorCode | A code identifying any error found in a send |
| SMS Template | |
|---|---|
| SMSJobID | The numeric identifier of the SMS send |
| SMSTriggeredSendID | SMSTriggeredSendID: The numeric identifier of the triggered send associated with the SMS send |
| BatchID | A number that identifies the batch associated with a Triggered Email Send event. It’s used to differentiate between multiple sends to the same Subscriber using a single Job |
| SubID | The SubscriberID of each message recipient |
| Push Template | |
|---|---|
| PushJobID | The ID of the job, or bundle of sends, that included the push notification |
| PushTriggeredSendRequest | TokenID that is returned from the API call. When you use list and data extension sends, this value will be the same as the PushJobID |
| PushBatchID | The ID of the batch, or bundle of jobs, for batched sends |
| SubID | The SubscriberID of each message recipient |
| DeviceID | The ID of the device that received the push notification |
| AppID | The ID of the app that received the push notification |
| LogDate | The date that this data was written to the send log |
These fields contain information generated by Marketing Cloud Engagement, and these values can’t be modified.
Data Format and Types
Because the send log uses a single data extension, it’s best to keep the data to a minimum. Streamlining the data is important because very large data extensions can take a lot of time to store and index data. Think of it like streamlining a bicycle for maximum speed and efficiency. Ditch the bell and streamers—we’re aiming for top performance! Here are some data extension guidelines to get you there.
- Use fewer than 20 fields, if possible—and definitely no more than 100 fields.
- Use fewer than 3,000 characters worth of information across all fields for an entire row.
- Define lengths for text fields to avoid cramming too many characters into a field.
- Refrain from setting any custom fields as primary keys.
- Make any fields added to the send log nullable.
After you define the data you want to include, you have to decide how much data you want to keep. And that can add up. Sends can generate millions of rows of data, so you need to make sure that you manage that amount, extract what you need, and get rid of the rest. Check out these guidelines for maintaining your send logging data extensions.
- Set up a data retention policy to clear out data that is no longer needed or has been extracted—typically a few weeks or months.
- Retain as few rows as possible.
- If data written to the send log is in excess of a few million per day, work with your Salesforce team to optimize for this volume.
- Keep the data in the send logging data extension only as long as is necessary to export to a different location for long-term storage.
- Perform marketing activities using data in long-term storage as opposed to the send logging data extension.
When you capture data, remember that the send logging data extensions capture only data related to a specific send and nothing else. If you want to combine that data with other information for later use, export it into a separate data extension using the ID values to match the data to your contact records.
Finally, if you capture data using programmatic languages, you can store JSON-formatted data in a single field. Meaning one field can store a great deal of information to improve the performance of the send logging data extension.
Send Logging for Business Units
Earlier in this module, you learned that you can only use one send logging data extension per MID. And if your tenant uses multiple business units, there’s a good chance you’ll be sending many messages that log information to your send logging data extension. Consider setting up send logging data extensions for each of your business units. Here are some ideas for how you can divide up sending responsibilities across business units.
- Dedicate a business unit to test sends, so you can try out new approaches without affecting the quality of your send data.
- Dedicate a business unit to transactional sends to keep that data separate and keep send log entries to a minimum.
- Dedicate a business unit to large, planned bulk email sends to separate those events from ad hoc and Journey Builder-based sends, allowing both those sends and the send log writing process to continue smoothly.
Using different send logs ensures you can capture all the necessary attributes and related send data you need.
Next Up
You’ve got the basics for how to think about and plan for send logging. In the next unit, let’s take a look at how exactly you get send logging data extensions into your account.