My name is Eric Saupe. I work for Deseret Book, a book publisher focused on selling Christian and Latter-day Saint products and founded in 1866. We have over 20,000 salable variants including digital products like ebooks and audiobooks. Those products are sold in our 45 retails stores and authorized reseller locations as well as online. We have an e-reader app called Deseret Bookshelf for iOS and Android, and we just launched a subscription service for unlimited access to our audiobooks and over a thousand ebooks. All purchases for Deseret Bookshelf happen through our Solidus-based DeseretBook.com, and our online orders for physical products are fulfilled through our own warehouse, which runs on Oracle and Logpro. Our physical products include books, art and home, jewelry, and clothing. Hopefully that gives you a small glimpse into the breadth of products we sell and services we have to communicate with through our Solidus store.
The other trick was scheduling deploys. Since they would often be advertising sales on the homepage, we would need to make sure a developer was ready to deploy at midnight to ensure the sale turned on and off properly.
I’m sure a lot of you have experiences that are probably pretty similar to that. Back then, whenever there were storewide sales, we would create a Category of products—a category is what we would now refer to as a Taxon—and place all of their Sale Products in there so they could link to that in their emails. I actually like that approach, but you can see how time consuming all of this would be.
On our homepage there was a Top Ten list that was somewhat automated albeit misleading to the consumer. It took all products sold in the last two weeks and figured out which ones gave us the most revenue. So it really wasn’t the most “popular” since we could have sold a single $2,000 painting and 600 $3 bookmarks and the single painting would be more “popular” to the end user.
It wasn’t all static though; we did use Adobe Target to selectively inject some neat things to users but only in a couple of places. At the top of the page under the navigation we could add messages to the user about sales or site updates. That was more or less all we had as far as tools go for the marketing team. Everything else was done by hand by either the marketing team with their Category pages or with the help of the developers manually updating the homepage.
With that we let Adobe Target control all sections of the homepage. Images, text, and links were all given to Adobe Target to allow marketers to update whatever they like. This was pretty good in theory, but it had a lot of negatives in practice. For one, if Adobe Target was down, the homepage was empty. Also, many ad-blocking plugins blocked Adobe Target data entirely because it was requested from the client rather than the server. Our client base is not really likely to use ad-blockers, but as developers and for our more tech-savvy users, the homepage was basically blank. There was no default content served from the site itself; it all relied on Adobe Target.
This gave us a few ideas to improve and iterate on, though. It allowed for A/B testing, which led us to find that a curated Top Ten list outperformed the existing automated one. The marketing team also loved having more control over when homepage updates were released rather than relying on our busy schedules to squeeze in development and deploy times. But the flaws of Adobe Target were too much, and it was clear we needed to phase it out at the end of our contract.
So what were our options at the time? We could build custom tools for them right on top of Spree, but then we would need to maintain the new database tables, bug fixes, and still have deploys for those changes. As developers we wanted something with minimal maintenance that the marketers couldn’t mess up. That may sound harsh, but with Adobe Target they were given the power to drop in entire blocks of Javascript, and if there were errors in that Javascript, the pages would break. That’s when we found headless CMSes like Contentful and Prismic.io.
A headless CMS gave us the low maintenance backend that we wanted. It maintains the database and the service for you. It provides the GUI for users to update data, and it will integrate with all of your applications because the data is returned as a JSON object. Many of them also have gems to get up and running quickly. Their GUIs are great for non-technical people, giving them WYSIWYG-type editing that they can save and collaborate on before publishing.
Marketers are in charge of publishing, leaving the developers to focus on developing new features and fixing bugs. We didn’t want to store marketing data in our database because that would add unnecessary complexity and maintenance onto our small team. Outsourcing our marketing data management and publishing to an API-based CMS allowed us to focus on growing the business and let the marketers move more quickly without having to wait for developers to start selling product.
This was also a great time to implement a new Prismic marketing change, and so we began talking with the marketing team about exactly what would be useful to them. We came up with a few components they wanted to use around the site like sliders, hero banners, mini banners, carousels, multi-item carousels, and headings. Knowing what kinds of content they wanted to place around the site, we simply needed to constrain those elements in a way that was both predictable for the site and simple to create and update for the Marketers.
To accomplish that, we created Content Schemas in Prismic. These house all of the data about your component, things like name, product ID, display type, etc. I’ll go over an example of one of these components here.
This is the Content Schema for a multi item carousel. First we see that the Component is a Carousel with the tag “Multi item,” which helps distinguish between two or more types of the same component. Then each item in the Carousel is displayed with data about it: product name, description, custom link, button text, product SKU, and a custom image. Marketers can quickly update information that is specific to this Carousel without changing any data in our storefront. To identify where to place these components, we use Prismic’s tagging system with defined tags to be pulled into specific locations in our store. For example, anything that needs to appear on a specific taxon page is tagged with the taxon slug like “art-and-home/framed”.
Once the schema is set up and a component created, the site needs to pull in that data from Prismic and display it. We do this by making a call to their API and fetching documents related to a tag based on the page we are currently on. For taxon pages, we pull documents tagged with the current taxon’s slug. Now we have a JSON object with documents that should be rendered. Since this is just JSON and not HTML, we create partials to translate the Prismic data into something more meaningful.
This is our partial for carousels on our site. It handles both single-item and multi-item carousels and renders differently based on the type returned from Prismic. Here is where we are ensuring that the way things are rendered is consistent and within our predefined guidelines. However, in order to encourage a pattern of controlled content entry for flexible content presentation, Prismic does not allow for raw HTML. In our case we are going to handle all the HTML rendering based on the fields entered in Prismic.
Custom names, descriptions, and images are rendered from what was input in Prismic, but we also give the option to simply put in a SKU and handle the rendering from within the store. At Deseret Book we rely more heavily on Variant SKUs than anything else, but you could just as easily use the Product or Variant IDs to specify an individual product you wish to market. This makes life easier because custom data is not required, and it allows the site to consistently render the proper link and image.
Now that you have an idea of what an individual component looks like, let’s take a look at our big project of allowing Marketers to update the entire homepage from Prismic. Each section of the homepage is a different document housing many components. We have our top section, which has a hero banner and mini banners; our left section with carousels, single item spotlights, and headers; and our right section with our curated Top Ten list and some single-image components.
The home page looks exactly the same as it did before we implemented Prismic. Because everything is just a partial in Rails, we were able to match our current site without problem, and we also maintain consistency throughout the site since every Prismic component will render the same way on every page. Hero banners on taxon pages look the same as the Hero banner on the home page.
We also integrated Prismic into our mobile apps, and it is now the central location for marketing across all of our sites and allows marketers to quickly make updates and changes to our web and mobile apps. This saved a lot of money in possibly getting another solution that focused on just mobile in-app marketing.
Here in Prismic I’m editing the home page section to change an image. I can save it up here, then we can preview it on the site, live. Once I’m happy with it, we can either schedule a time for it to be published or just publish it right now. In addition to scheduling a time, Prismic allows you to create releases, which lets marketers work on an entire series of changes and lump them into a single event that will all be published together. Last year they used it with great success for the 12 Days of Christmas sales we do. As you change and make edits to documents in Prismic, it will keep track of the differences. You can even fork different items to make changes just like Git.
I’ll publish it now. We’ll go back to DeseretBook.com and you can see my change is now live.
To help you get started with all of this, I am announcing two gems, one for Prismic and one for Contentful that will plug into Solidus. Included in those gems are starter templates for basic marketing components. We have loved everything about what Prismic has given us, and I really hope you’ll consider using an API-based CMS to enhance your store too. Thank you.