Improving Our Affiliate Marketing Strategy

Refinery29 P&E
Refinery29 Product & Engineering
5 min readFeb 3, 2017

This past summer Refinery29′s Product & Engineering team hosted three talented interns, who worked on different projects pertaining to (1) email acquisition improvements, (2) enhancements to our digital asset management system in our CMS, and (3) our affiliate marketing strategy through shopping products. Below, Maggie Love, who worked on affiliate marketing, recaps her project.

This article was originally published on September 20th, 2016

As a member of Refinery29 Engineering’s shopping team, I spent the summer working on ways to improve how shoppable products are featured on the site. To do this, we wanted to first find out more about our most popular products. We then wanted to give writers and editors better tools to use when integrating those products into their content.

What’s Working?

The way our affiliate marketing model works, when a reader clicks an external product link from an R29 story and makes a purchase, Refinery29 gets a small commission for being the referring site. The API we use to track users’ clicks and purchases provides us with information about the number of orders, order value, and our commission rate. Given this data, we wanted to give our team a quick, regular snapshot of the best performing products according to these metrics. We did this using a Python script that this data out every Friday in an email, which we call the “Top Products Digest”.

ABOVE: An example products digest email.

The data we needed was available to us through reports in Domo, an application we use to create datasets from various sources. We formatted this data into email-friendly tables and used the Postmark API to send the email to an internal listserv. We also programmed the script to timestamp the titles of the datasets we downloaded from Domo as they were named, then upload them to an Amazon Simple Storage Service bucket for future reference. The program is hosted on Linode, and the script is run through a weekly cron job, with daily and ninety-day options as well.

From the data collected and sent in these emails, so far we’ve seen an interesting mix of highest performing products on the site–some are tied to time-sensitive sales, some are products readers are less likely to see on other sites, and some are evergreen. Given the variation we’ve seen, at this point we’re still exploring possibilities for how we might best use this information.

Integrated Products vs. Text Links

There are currently two ways Refinery29 features products in a story. The first–and ideal–way consists of a featured product module embedded in the page, with brand, retailer, and price information. The second is a plain-text description of a product accompanied by a hyperlink to the retailer’s site.

ABOVE: An example of integrated product modules on www.refinery29.com/baby-bags.

ABOVE: An example of a plain-text product description with a link out to retailer’s site on http://www.refinery29.com/everlane-leggings-stretch-skinny-pant-review.

In both cases, the reader sees the same information about a product, but with the embedded products module, readers are given an at-a-glance view of all items in the story without having to click slides or scroll through a story, the way they would have to with the link-only implementation. As you would imagine, the product module encourages more engagement from our readers. Additionally, embedded products are stored in a Refinery29 products database (which we can use for many things), while products featured as static images alongside text links are not.

It’s clear that the integrated product modules are the preferred way to go but the catch is that to create them, it’s a non-trivial amount of addition work for our editorial team. Especially when weighed against the effort it takes to create a hyperlink (a.k.a almost none) it’s clear why they don’t always have the time to create the product integrations. The challenge in front of us was to find new ways to show product recommendations to our readers without significantly impacting our editor team’s workflow.

Backfilling the Database & Moving Forward

For our first task we set out to backfill our product database with all of the shoppable products on the site that were only added as text links (and were therefore not in our database). After building a proof-of-concept “product scraper” using Python, Beautiful Soup, urllib2, and Flask, which accepted a retailer and product page URL and returned product information as JSON, we realized the maintenance this would require and ultimately reached out to Semantics3 for help. With the information gathering portion of the project basically figured out, the next step was exploring our two options for adding products.

We wrote a program that scrapes recently published stories for links to products and sends that data to Semantics3, which then returns information about each individual product. With this information, the program creates products in our Refinery29 database, then makes associations between these products and the articles in which they were referenced. So, when you return to a story that previously only had a hyperlink to a product, an embedded product now appears… no editorial team effort required.

With this part done, our goal now is to create a better product creation workflow for our editors, one that will pre-populate our CMS product form with the data we get from Semantics3. With this, our editorial staff will be able to generate integrated products modules in articles much faster and at the time of publication, rather than post-publication, like we do with the backfill process.

ABOVE: A view of the shopping product form in our CMS, the tools editors use to create and associate shopping products to their stories.

At the time my summer internship ended, we were just beginning discussions with our CMS engineers and UX team members to brainstorm how we could best do this. Having since been hired to work with Refinery29 full-time (woohoo!) I am continuing to help build out the new product form, which we plan to roll out to select editors for beta testing. Stay tuned!

Maggie Love, Software Engineer

--

--