A Better Way to Track Email in Salesforce
Salesforce includes 100MB of data record storage per user license. The Salesforce Foundation grants nonprofits 10 user licenses, which means that most of our Salesforce consulting clients have a 1GB limit on data record storage. Using an integrated email broadcasting platform that reports data back to Salesforce can very quickly consume this limited data storage space.
The main reason for this is that most integrated email broadcasting solutions use their own custom object to track email results on a per-contact basis. This is a relatively inefficient storage strategy. For each email sent, this approach uses 3KB of Salesforce storage per email recipient to track the email send results (campaign member is 1KB, plus 2KB for the custom object).
This doesn't sound like a lot, but given the number of records that email broadcasting generates, the storage load quickly mushrooms out of control. Consider the following example:
- An organization's Salesforce database contains 25,000 contact records
- The organization wants to send a weekly email broadcast to all 25,000 contacts and track the results per contact
- For each email sent, the current integrations are creating 3kB of data.
- 25,000 sends X 3KB data storage per send = 73MB of data per email blast
- At this rate, an organization will exhaust its data storage limits in approximately 13 weeks!
- Organizations can purchase additional storage space from Salesforce, but it's quite expensive -- approximately $1200/yr per 500MB. So, storing the data associated with a weekly blast to 25,000 recipients would cost nearly $9000/year!
While most of our clients are not burning through data storage quite that fast, since they're not emailing their entire list each week, several have shown trajectories to reach their storage limit in less than a year from when they begin integrated email communication activities.
Barring changes in Salesforce's data storage policies, Groundwire believes that the current approach most email broadcasting providers are using for data storage in their Salesforce integrations results in unsustainable costs.
We believe that significant improvements in email broadcasting data storage efficiency are easily achievable, by using Campaign Member objects as the point of integration, rather than a custom object. Groundwire recommends that email broadcasting providers who integrate with Salesforce adopt this strategy for reporting data back to Salesforce.
Here's the outline, followed by a proposed schema:
- The best place to store email broadcasting results data is in the Campaign Member object, not in a third-party custom object such as VerticalResponse's "Email History" object or ExactTarget’s "Individual Email Result" object
- Email broadcasting platforms should add several custom fields to the Campaign Member object to track email results
- Custom objects which track aggregate data such as ExactTarget’s "Email Results" object may still be used as only one object is generated per email campaign, and this does not contribute significantly to data storage bloat
Using the Campaign Member Object
- Create new checkbox fields: Opened, Clicked, Bounced, Unsubscribed
- Create new number field: Number of Clicks
- Create a Text field for the Campaign ID
- Create a Text Area (Rich ) field called Clicked Links - This will be the field which captures the actual URL of a clicked link (or links)
Proposed Schema for New Fields
Campaign Member Field Name
Unique per campaign
|| Text (string)
|Opened|| TRUE, FALSE
|| Checkbox (boolean)
|Clicked|| TRUE, FALSE
|Unsubscribed|| TRUE, FALSE
|Bounced|| TRUE, FALSE
|Number of Clicks
Unique per campaign
|| Numeric (integer)
Unique per campaign
|| Text area (rich lines field)
Note that Email Opt Out on the Contact record should be checked automatically as part of the integration when there is an unsubscribe.
Figure 1. This chart shows a hypothetical data usage scenario. The x-axis is months, and the y-axis is in MB. Both lines start with a baseline of 200MB or roughly 20% of data storage used for records like Contacts, Accounts, Opportunities, etc. After 15 months of sending 20,000 emails per month, the non-mitigated example would run out of storage while the other would only use about half of the available storage in that time.