About a month ago, Bronto released single-send API aggregation for deliveries. Full disclosure – I work for Bronto, but on the apps team, not the main product (by the way, buy Socialite), and I certainly don’t speak for them – everything here is my personal opinion and observations. This was a good change that improved the performance and efficiency of what was 1 of the more expensive API operations. That’s fantastic, but it also impacts the API in ways that Bronto developers are going to need to be aware of.
How this impacts people using the Bronto API
First and foremost, delivery aggregation is a best-effort process. The main criteria is sending the same message to different recipients during the same day. When in doubt, it’s going to just create multiple deliveries (for example, sending the same message multiple times to 1 email address will lead to multiple deliveries in Bronto). So you’re not necessarily going to end up with 1 delivery ID for the aggregated deliveries, but you will still have considerably fewer than what you were seeing before.
Keep in mind that the aggregation is per-day based on the customer’s time zone. If you’re an app developer, you can’t just check your local system clock to know if the aggregations have rolled over yet. If you really want to maintain the aggregations in your app, check the send date for the delivery – the aggregates will all be midnight for the customer’s date when the message went out.
Next, when you make an addDelivery() call, the ID(s) you get from the ResultItem(s) returned don’t necessarily correspond to a delivery that you can look up in Bronto. Eventually, 1 (or more – it’s a best-effort aggregation, remember) of the IDs you get from your single-send deliveries will return delivery data, and that data will have the stats for all your single-send deliveries attached. Just don’t expect to be able to start looking up delivery stats from an ID just as soon as you’ve sent a message.
In the meantime, you could look up deliveries associated with the ID of the message you sent, but beware. Aggregated single-send deliveries now show as being sent to a list, not an individual contact – so you can’t differentiate between messages sent to a list and those sent to individual contacts. By the way, the ID associated with that “list” – doesn’t belong to any list of yours, so you also can’t look up the contacts on these lists, so don’t think you can work around it that way.
Lastly, since most of the IDs you’ll get back from your single-sends aren’t going to be valid delivery IDs, you’re not going to be able to add the “deliveries” to delivery groups either. Basically, short of periodically checking to see which of the IDs return delivery data for the deliveries you sent on a given day, there’s no way to get the stats from single-send deliveries via the Bronto API.
So what does this change do for me again?
Like I mentioned at the beginning of this post, this change brought a lot of performance improvements to something not only was the least efficient means of sending a message, but is also something that is probably very common as marketers move towards more personalized messages triggered by specific actions or behaviors from that consumer. It also does a great job of cleaning up the huge list of deliveries shown in Bronto. For most people, getting these stats already aggregated is a huge help. In fact, it only really becomes an issue if there are other things related to the delivery you want to track delivery stats for.
What can I do?
If you are associating delivery stats with things other than aggregated deliveries, the first option for working around the aggregated stats is to use different messages for the different sets of stats you’re trying to track when at all possible. That way the aggregated delivery stats are independent of all the other deliveries and stats you’re sending out.
Another potential workaround revolves around the fact that at least 1 of the IDs you get back will be a valid delivery ID. If you track all the valid delivery IDs you have for a given day (in the customer’s time zone) then you can just track delivery stats that way. It doesn’t work for scenarios when you need to get stats from individual deliveries (because they’re associated with other specific data points in your application), but it is a way to pull the aggregated stats out of the Bronto API.
It’s also theoretically possible to get single-send aggregation turned off, but that’s an option of last resort that’s only going to be considered in the most extreme circumstances, and only if none of the other workarounds work in your situation. Personally, I’m hoping Bronto updates their aggregation so that it’s still possible to look up individual deliveries based on the IDs we get back from addDelivery() calls, but the reality is I’m in a tiny minority of people who have single-send deliveries that needs to break up the delivery statistics by those individual deliveries.
However, it’s important that single-send deliveries still be as fast and efficient as possible, which means not losing the benefits that we’ve gotten from aggregation. Between Bronto’s automated workflows and integrations like Socialite, single-send deliveries are the rule, not an exception, and it’s important that both Bronto’s platform are tuned for it, as well as their API. So far, the platform is off to a good start, I just hope the API catches up soon.