I’ve spent a disproportionate amount of my time over the last year thinking and talking about Personalization in Drupal (just ask my wife), and I’ve had the privilege of working with a brilliant group of people to help design and build a solution for it. Since we launched Lift in February, I’ve also given a large number of demos and discussed Lift in great detail with organizations large and small, learning ever more about what the needs are in the market, and stealing..err..borrowing ideas from them as I go along.
This post marks the first of a multi-part blog series where I hope to distill everything I know about Acquia Lift as a product, as well as personalization, testing and targeting more broadly as we implement these tools.
What’s this Personalization stuff?
When I use the word “personalization”, I’m talking about showing different things to different site visitors, depending on the visitor’s context. That’s it. I’ll unpack that statement a bit more, but the whole idea is that example.com/my-page can look different for you than it does for me. At it’s most basic level, this could be due to an A/B test being run on the page and you’ve been randomly selected to see a different variation than I have. It could also be because of some targeting rules, so that you’re seeing a variation that’s targeted for people in your geographic region, while I’m seeing a something targeted for people in North Carolina.
The rules can get a lot more complex than that, but it all boils down to Visitor Context. What can we learn about visitors coming to our sites, and how do we then display different things to different people?
What can I learn about Visitors coming to the site?
It turns out there’s quite a large number of things we can learn about site visitors, even before they’ve told us anything explicitly. Here’s an incomplete list:
- Geography — what city, state, country, or classifications about those places such as demographic information.
- Device — What browser, device type or operating system is being used.
- Referral based — Did you come from social media? email? Google search?
- URL parameters — Used to tie a visitor to a campaign or a particular ad or email that they saw before coming to the site.
- Business based — If you’re using a corporate IP address, what company, company size or industry are you coming from?
- Behavior based — If you’ve spent a little time on the site, what are your expressed interests and what are you searching or browsing for on the site?
The list goes on and can sometimes go into areas that are a bit more gray, such as 3rd party cookie tracking services which can tell you about what a visitor has been browsing for on other sites. You're unlikely to see a blog post from me on how to use those .. but they're out there.
What about anonymous visitors and site performance?
This may all sound great, but for the Developers reading this, you’re probably wondering about performance and caching. From a technical perspective, that was one of our biggest concerns as well, so let me spend a little time on this.
There are roughly three ways we could have approached this problem, all with some pros and cons. At one extreme, we could build an external platform which hooks into our sites through a Javascript tag and manipulates the DOM (the HTML of the page). This works well with site caching strategies, and for sites with a legacy CMS where it’s really hard for a marketer to make changes .. but what about when you have a CMS that’s well tuned for your marketers to use? Do you really want to edit content in two places?
At the other extreme, we can do really rich personalization inside of the CMS as you’ve been able to do with Drupal for a long time, or you can do the same with Sitecore or Adobe’s personalization systems, but then you’re completely reliant on the CMS, and that means lots more servers. (By the way, with those proprietary systems, you pay for CMS licenses per server, not just the additional cost of the servers).
So is there a middle ground? Well, that’s what we set out to build. We still make heavy use of Javascript as in the first version at run time, but then we use Drupal’s immense flexibility to allow authoring and management to still all happen within the CMS, giving you one canonical source for content and one login to manage for your marketers and content creators. This balance allows us to still do full personalization for anonymous visitors, even when using full page caching with Varnish or serving entire pages through a CDN.
(OK, so there are actually other ways to approach this problem as well, such as Edge Side Includes, but those are very implementation specific and therefore a much harder thing to build into Drupal modules in a flexible way).
High-level Lift architecture
“Enough of this overview stuff .. how’s it actually work?!”
Ok, ok .. I’m getting there.
So there are roughly 3-10 components that make Lift work, depending on how detailed you count. The first three points below have to do with Drupal modules, so here's what those look like:
1. The Personalize Module
The Personalize module is the core Drupal module that gives us a personalization framework to build on. It handles things like swapping out pieces of a page with Javascript, tracking Visitor Context (as discussed above) and providing a number of plug-ins to extend the system for doing all kinds of neat things. I’ll go deeper into this in a later blog post, but the big takeaways? This can be extended for your own uses and is completely free and open source to plug into any Drupal Site today.
2. The Visitor Actions module
If you’re going to increase conversions, you need to track those conversions. With Visitor Actions, we built a flexible framework for tracking any action on the site, whether client side or server side, and a UI to easily allow non-technicaly people to set these up in the context of campaigns. This probably warrants its own post as well, but the big news here is it’s got a slick UI and it can be used outside of personalization for things like Analytics custom events, Marketing automation and Gamification. I hope to see it adopted more and more in those areas over time. The UI looks like this:
3. The Acquia Lift module
The Acquia Lift Module serves two purposes. A) It adds some nice-to-have but not essential UI elements to personalization. We put this here because we want the Personalize module to be as extensible as possible with as few dependencies as possible. B) Connects to the Acquia Lift service (described next).
4. The Acquia Lift service
OK, so everything above is free and open source Drupal modules, so why have a SaaS service? Well, remember how I said this will work with full page caching? If you’re going to do more sophisticated logic, you’ll still need a service to make some decisions for you. That’s where Acquia Lift comes in. This is an API based web service which handles A/B testing, MVT testing, auto-personalization based on statistical models, and a variety of additional Visitor Context such as geo targeting. One neat thing is that you can use the modules above without subscribing to the service. Later blog posts will detail some pretty neat personalization you can do without a subscription, but for now I digress.
5. TruCentric
We recently announced that a Toronto based company called TruCentric has joined the Acquia team. They bring a lot of powerful capabilities to what’s described above, but the initial piece that we’re rolling out shortly is behavior based targeting. This means that you can learn about a visitor’s interests while on the site and tie that across sessions and devices to deliver truly personalized experiences to each visitor on the site. This warrants a few posts on its own, so I’ll leave it at that for now.
There are sub modules in a number of these and lots of things that Lift and TruCentric can do, so that’s why I said 3-10 depending on how you count.
Questions? Comments?
As I said, this is way too much to cover in a single post. Some future posts will include a deep dive of the Personalize module, how-to walkthroughs of specific things you can do with the service, tips and tricks for getting the most out of A/B testing campaigns and targeting, and much more.
What do you want to know about this stuff? Please add questions to the comments here. If they’re quick answers, I’ll try to go into it there. If they’re longer answers, I’ll put the answer in it’s own blog post. You can also reach out to me on twitter at @daveaingram.
Talk to you soon!
