Ingram moved its book-marketing audiences from Salesforce Marketing Cloud into HubSpot
The Customer
Ingram distributes books and provides services to publishers. Its consumer-facing sites, such as Bookfinity, help readers find their next book, and its ShelfSavvy data holds what those readers are likely to want.
Before this project, Ingram ran its email marketing in Salesforce Marketing Cloud and its behavioral audiences in Interaction Studio. The work to move both into HubSpot began in December 2024.
The Challenge
Moving email lists from one platform to another is routine. Ingram’s harder problem was that its marketing depended on behavior. Audiences were built from what people browsed on the book sites, and the recommendation emails depended on data that lived outside the marketing platform. All of that had to be rebuilt on the new platform.
Three pieces had to arrive together. The subscription lists and opt-in and opt-out records had to come across intact. The website events that fed the audiences had to be recreated on the new platform and placed on every Ingram site. And the ShelfSavvy book recommendation emails had to run on the new platform’s own tools.
The Solution
The engagement opened with a demonstration of how the existing Salesforce setup worked, so the data model for the new platform could be designed around it. That model and an integration plan were implemented in the first weeks.
The Marketing Cloud migration followed a written export strategy for the master lists. We supported the list imports and recreations and migrated the subscription opt-ins and opt-outs.
For Interaction Studio, we documented the audiences, their filters and the properties behind them, created the properties the platform needed, and recreated the lists.
Custom website events replaced the old behavioral tracking. We mapped the events already running across all Ingram websites, created matching custom events on the new platform, and wrote a code placement blueprint for Ingram’s developers. Audiences are tagged from the URL a visitor reads, with patterns for book category, article category, BISAC subject, academic category, EAN and author. To prove the data was flowing, we built six contact lists with page-view filters and six matching anonymous ad audiences, one per pattern. Anonymous audiences for Google Ads and Meta followed.
The ShelfSavvy email was the centerpiece. We wrote the integration blueprint and supported Ingram’s own developer while they built the integration that lands ShelfSavvy data on the platform. On our side we created a HubDB table and an active list, built a custom programmable email template that reads the table, and built the send workflow. When a contact has no known preference, the email falls back to nine books chosen at random from the Bestseller set, and long descriptions truncate with an ellipsis.
A second programmable email followed for reader types. Each reader type gets three content blocks, driven by a HubDB table. We later extended the module with a repeater field so the marketing team can place one or two banner images for chosen reader types after the first, second or third book.
We finished with QA of the migrated static lists and the active lists, and wrote documentation describing how the ShelfSavvy email was built and how it works, written for both Ingram’s technical staff and the marketer who runs it.
What They Got
Ingram’s marketing team now runs its lists, audiences and recommendation emails from one platform. Subscribers came across with their opt-in and opt-out status.
Browsing on the book sites still builds audiences. A reader who looks at a category, a subject, an author or a title lands in the right list and the right ad audience without anyone exporting a file. The ShelfSavvy email sends from a workflow, and the books it shows come from a table the team can edit. The reader-type email works the same way.
The team also has written documentation for the ShelfSavvy email, so they can maintain it and report on it themselves.
Wrapping Up
Our standard on a platform migration is that every audience and every automated send that worked before works after, and the client’s own team can maintain it without us. Ingram’s developers built the piece that was theirs to build, with our blueprint and support alongside. Lynton now builds AI-native websites on open infrastructure; see our current work at /case-studies.