Data integrations are our specialty. And while we’d love to say that they’re 100% accurate all of the time, in the end, technology is technology. It’s only as good as the people behind it. When errors come up, most of the time, it isn’t about the technology that is ‘integration’.
No, that technology will continue running the same way it was designed to run. It will remain that gate that opens once signaled, allowing data to flow from one system (AMS, EMS and future association systems) to another system (HubSpot). Then the field, field attributes, values, and lists that flow through are based on the business rules and requirements dictated by its owners—the associations and nonprofits that we serve.
When an integration isn’t working, about 99% of the time, it’s:
- The accuracy (or lack thereof) of their data
- The way the data is configured within the AMS
- The way tech assets are delivered
- Staff’s lack of understanding around their data or how to activate on it
The good thing—HighRoad gets it. Since we wear that human flag as well (no, we are not aliens over here ), we have years of experience reconciling blips and data misnomers. Consider us custodians for resolving nuanced errors. But we go even further than that—we’re also the curators of root cause solutions.
In fact, that’s what makes HighRoad’s Spark integration so failsafe and solid in performance. We’ve had 18 years of isolating variances, trapping them so that they never happen again, and building those solutions into our integration product. In a nutshell, our product learns from mistakes. Even if it’s the practitioners behind the missteps, it’s constantly evolving.
As the masters behind our integration and association data, we’ve collected our own set of best practices and pitfalls to avoid when it comes to working with our Spark integration. Let’s take a look at what’s proven to net the most efficient and effective Spark integrations:
1—Finding the keymaster
One of the first challenges for our clients lies in providing connectivity to their AMS’ API. While we’re there to walk them through every step of the process, finding the keymaster to the API is a critical step to the Spark configuration.
While we highlight this task at kick-off, it’s always a good idea for organizations to identify this individual as soon as possible, particularly when schedules are always tight. This moves the project forward that much sooner.
2—Technical assets are the meat—treat them tenderly
When it comes down to gathering business requirements for integration, it’s really about the org as a whole discussing what fuel goes into the association engine that drives revenue and engagement. That in itself is an undertaking. Luckily, HighRoad has a solid framework for guiding these conversations and helping organizations identify the right data for the job.
But where most associations get stuck—providing the technical assets that map to those business requirements. In other words, marketing, program, and even leadership teams may have a vision for what they want. And that vision is good. Real good. But, unfortunately, the data ingredients that would bring that vision to life don’t exist within the AMS. There’s either no a field at all, there’s a field that isn’t populated with values, or that field doesn't actually do what they want it to do.
Providing technical assets, on average, takes anywhere from a few hours to a few days to pull together. But, let’s face it—like all association professionals, association tech teams have a lot on their plate. That’s why we always relay at the onset that the org project manager and/or integration champion needs to keep all teams updated on timing and expectations. As part of our kick-off, we highlight the level of effort needed from all teams throughout each stage of the process. Getting in front of these teams, and particularly getting on the tech team’s calendar, is the ideal approach to turning those tech assets around quickly. It’s often a matter of reducing what would take a 2-3 week turn-around to a 2-3 day turn-around.
For the tech team—and more specifically, the team with their hands in their AMS—it’s important that they have open conversations with their marketing counterparts so that expectations are met. If the data isn’t there, that needs to be articulated back to the team who requested it.
HighRoad fortunately is positioned and committed to translating this speak between teams. We not only understand how Spark works and why it works in certain ways, we understand how to organize the data so that it performs the right way once it gets to HubSpot. Most importantly, we’re experts on association campaigns, and can help them activate their use cases through data.
But I digress. Back to data gaps. In the event an org uncovers aspirational data (i.e. data that they don’t have), we encourage them to put roadmaps in place to gather that data down the line. Now, that doesn’t mean Spark configuration stops. No, no, no. Spark was built with organizational change and data evolution in mind. As long as you have a Spark license, you can add as many additional fields and lists as you want, when you want.
3—Incremental syncing
Most associations think syncing the whole bag o’ data over and over again is the way to go. Nope. Not the case at all. Take our ‘One-to-Many Sync’ for example. This sync is designed to funnel multi-dimensional data (AKA parent-child relationship data like transactional event registrations) from their AMS to HubSpot.
Let’s say Association X has 300,000 member and customer contacts. They want to maintain historical integrity within HubSpot. In other words, they want a live feed of data flowing from their AMS to HubSpot on the reg. In their mind, they need to sync all 300,000 over everyday. Total fallacy.
Through Spark, orgs only need to sync the data in bulk once. After that, Spark only syncs new and changed data because HubSpot will recognize it, update it, and append that data when it comes through.
It’s examples like these that make Spark the ultimate steward of data. Sending droves of the same information over and over has a compound effective over time. Sending it incrementally keeps the data clean and sustains optimal sync performance.
4—Sure-fire ways we test your Spark integration
It’s obvious that Spark as a product has been conditioned over time to minimize glitches. But, once again, when it comes to complex pieces of technology that transport droves of data from one multiplex machine to another, human checks and balances are a natural part of the product.
That’s why HighRoad has a solid QA footprint in place during the configuration process. Put simply, we evaluate:
Whether the import goes into HubSpot successfully
We download data from the association’s AMS and import it into HubSpot. Then it’s a numbers game. We take a look at how many we downloaded from the source system and how many made their way into HubSpot. Typically it’s 99%. If it doesn’t go in, we look at the error log within HubSpot. We then resolve the errors one by one.
Whether there are errors
One example of this—after researching an error in the log, we find that there is an enumeration error. Enumeration refers to predefined values within a field. In this case, the Member Type field—which needs to be created as a custom property in HubSpot in order for the sync data to properly map to it—doesn't have Lifetime Membership as a dropdown value. This will generate an error in the log. This is a field mapping error that HighRoad researches and reconciles as part of the Spark config process.
That's an example of an error where the field is populated but the values aren't mapping accurately. Other potentially occurring errors relate to empty fields. When a field is empty altogether, there are typically one of two reasons for this:
- The data coming from the source isn’t translating: in this case, we review and adjust the config file accordingly
- There is no data coming from the source: in this case, this is a data gap that needs to be roadmapped
The majority of the time, the errors come down to field mapping. This is why we provide our clients with Technical Specification documents. These Tech Specs act as instructional guides for our clients to follow as they build their data assets and custom properties within HubSpot. While it's never a perfect science, putting these measures and resources in place minimizes errors which can shorten the project timeline.
5—Sure-fire ways orgs test their Spark integration
While HighRoad has its own means to create efficiency and minimize errors throughout the project, our clients' testing measures post-config are equally as important.
Once Spark is configured, we walk our clients through what we call a Data Tour. This is our way of demonstrating to our clients where their data exists in HubSpot.
A Data Tour includes walking through all of the Spark end points in HubSpot:
- Contact Object ⇒ All Contact Sync
- Deals or Custom Object ⇒ One-to-Many Sync
- Lists ⇒ Source Segment Sync
Once we point out where the data lives, we then create a few sample lists using Spark data so they see first-hand how they can put their data into action. Finally, during the Data Tour, we walk through best practices on testing Spark, which include:
- Grabbing 2-3 people with their hands in their AMS to validate whether the data is accurate
- Comparing AMS counts to HubSpot counts, keeping in mind that standard count match rates are typically 98%, not 100% (see below)
- Pulling a sample of contacts (3-5) and checking that all properties related to that contact are populating and accurate
6—Don’t count on a 100% count match
When it comes to validating count matches, keep in mind that you're never going to have a 100% match. Once again, 98% is optimal. Anything drastically under that percentage should be researched. That's where HighRoad comes in to troubleshoot the variance.
Keep in mind, when deviations bring the count match to under the 98% mark, the variance is most likely attributable to one or more of the following factors:
- HubSpot won’t let bad email addresses in
- HubSpot won't let unsubscribes in
- In cases where a unique identifier is used (versus an email address), if that identifier is doubled or missing, HubSpot won't let it in
- If there are too many fields associated with a contact with bad data in it, HubSpot won’t let that contact in
The future of Spark looks alert
While Spark is already a sturdy and steadfast performer, we're always looking for ways to enhance precision and mitigate error even more. Future Spark releases will include:
- Error Capture—through this feature, Spark will automatically capture errors, log them into a database, and make them user friendly so that orgs know how to take action to correct the error.
- Connectivity Capture—through this feature, Spark will automatically alert users that connectivity isn’t working and will provide detailed instructions on reconnecting.
- Count Capture—through this feature, Spark will automatically send an alert when there's a drop in a list count in our Source Segment Sync. Once it's flagged, the org (with HighRoad's support if necessary) can research whether there's a true error or whether the count drop is accurate to what's sitting in the AMS.
Once again, Spark is just the conduit for transporting data from nearly any AMS within the ecosystem to one of the most powerful omni-channel marketing automation platforms out there—HubSpot.
As such, marketers evolving to Spark + HubSpot are typically moving from a prominently list-driven culture—where the fields are buried in the lists—to one of logic, filters, and triggers. This can be immensely overwhelming and can be a huge change in thinking. That's why, data organization, data literacy, and particularly data activation training is so important.
Better data integration means better data activation
As stewards of association data, we at HighRoad are committed to leveling orgs up on data activation. Learn how HighRoad Spark + HubSpot can quickly put you in the results zone. Book a consultation today to learn more.