We originally posted this in mid-August, to give you the lead time to develop this scenario, but with Black Friday and Cyber Monday right around the corner, we thought a re-post on this subject would be timely.
These once-a-year mega sales require careful planning and execution, often across multiple departments. As business events go, there's nothing more complex, costly, or time consuming than this.
In addition, online events are difficult to test, because you have to hide the URLs from enthusiastic customers, hackers, and attackers. Some organizations opt to not to publish the pages/URLs before the event, but that's not only error-prone, it also requires perfect coordination within organizations.
In this blog I show you how to implement an alternative solution: serve a marketing page until the day of the event and automatically lift and close the curtain at specific times. You can release the event URLs at any time after setting the solution up, so you can start marketing right away. All the while, development and testing carries on safely behind the scenes.
This solution uses the Visitor Prioritization Cloudlet, which is typically used to control flow during traffic spikes. But as I'll show you in this blog, you can also use it for e-commerce events. And not just mega sales, but really any kind of sales event. As you'll soon see, it's a good fit for weekly promotions, flash sales, previews, special releases, invite-only, or sports/social related promotions.
Sample Use Case - Black Friday
To show you how this works, let's start with the mother-of-all sales, Black Friday, and a massive 90% discount on selected items. The marketing team has the following requirements:
- They don't want customers to know which items will receive this discount; therefore, I can't let people or bots find the page before the event.
- Marketing wants to send an email blast one minute before midnight on November 24th, and the page must be live immediately after. The sale must end precisely on Cyber Monday, at 10 PM EST.
- Everything needs to be set up well in advance, so I don't have to worry about it during the holidays.
As stated, I'll use the Visitor Prioritization Cloudlet, and implement the following rules. I'll refer to them by their Req # (requirement number) in this post:
|Req #||Start Time||End Time||Requirements|
|R1||Now||11/24/17 23:59||Site is not publicly available Internal teams must have access|
|R2||11/24/17 23:59||11/27/17 22:00||Site is publicly available (flash sale)|
|R3||11/27/17 22:01||Never||Site is not publicly available Internal teams must have access|
Step 1 - Create the Marketing Page
First, let's create the marketing page visitors will see while the site isn't publicly available (R1 and R3). To do so, I download the waiting room template page from Luna (Log In and then Support --> User and Developer Guides --> Cloudlets) and ask my creative or marketing team to provide a nice looking, enthusiasm raising page. OK, so it looks like my team (aka me) isn't very creative. Anyway, this is how it looks:
Step 2 - Create a Visitor Prioritization Cloudlet
Next I create a Visitor Prioritization Cloudlet to control when the scenarios will kick in.
Step 3 - Create Rules to Control Traffic and Access
Now I'll create a rule that will send all the traffic, from now until Black Friday, to this waiting room page (R1).
I also need to grant access to my QA, developers, and content owner folks (aka me, myself, and I) with a secret cookie. However, a cookie by itself is not a secure mechanism, so I'll add an extra layer of obscurity by base64-ing the cookie name (AmITesting?) and value (YesyouAre). This is easy to do by visiting Base64 Decode and Encode - Online.
I'll also create a rule to end the event at midnight on Cyber Monday (R3). I want to apply the rules to the event page only, as I don't want to impact traffic on the rest of my site.
The marketing URL for my event is /services/ (I know, very interesting SEO selection). The result looks like this:
It's OK to activate the policy version in Staging and Production right away because the URLs aren't live. Once the developers finish the promotion URLs they can deploy it and start testing using the secret cookie. The rest of the Internet will simply see the waiting room page.
I've kept things simple here with one time zone, but I could actually start or end the event at midnight local time. To do so, I would have used the geo location match to set different rules per time zone.
Pro tip: Test the release by cloning the policy and changing the dates to see it in action. Perform the test on a different URL as you don't want to grant access to the holiday page yet. Since you're simply testing the mechanism, the test URL could be a blank page or 404, Not Found.
Step 4 - Attach the Policy to the Host Domain
With the rules in place, I can now attach this policy to the domain hosting the event; e.g. www.manuel-store.com. The behavior I add to the configuration is called Visitor Prioritization, and you can get a free trial from the Akamai Marketplace if you want to play around.
Notice that I set up the membership to 300 seconds. The membership will let the visitor stay on the site after I shut down the page in case she/he is shopping. I recommend using twice the average session time for the duration.
I'm creating the two rules (before and after event) together, but you could have different waiting room pages to provide a different experience. Another alternative is to create a redirect to the homepage that kicks when the event ends (you can do that with Edge Redirector).
Step 5 - Push to Staging
Now I'm ready to push the changes to Staging.
To test in Staging, I move the date on the policy to today, a minute after I want to start testing. I test it by loading the blocked URL. First I see the nice marketing page, and then a minute later the page reloads by itself, giving me access to the sale page. I'm ready for Black Friday now!
That's all there is to it. If you scrolled up again looking for R2 implementation, you won't find it. R2 is letting the requests come in and you don't need a policy for that.
If you're concerned about traffic spikes during the event, then you should create a new rule to throttle traffic. That's the classic Visitor Prioritization use case, and a minor addition to this solution you should be able to handle on your own.