« Power of Personalisation | Videos From Down Under »
Magical PURLs
The term 'PURL' has definitely gained attention over recent years, establishing itself alongside industry acronyms including CTP, JDF, VDP and others. Today, it seems that everyone is talking about PURLs — from print providers through to vendors. Despite all this talk about PURLs, not many people really understand what the heck a 'PURL' actually is.
Outside the realm of direct marketing, 'PURL' is an acronym for Persistent Uniform Resource Locator; a URL redirection technique where an intermediate resolution service serves client requests for a defined URL and associates the request with the 'actual' URL on the web server, returning it to the client.
The use of the term 'PURL' within direct marketing refers to 'personalised URLs'. the acronym 'PURL' was first coined (and trademarked) by marketing solution provider Nimblefish. While the term 'PURL' may have been snatched, it hasn't stopped other vendors and providers from adopting variations of the term. Pageflex, MindFire and Indros Group use the term 'Personalised URLs', while XMPie coined the mouthful 'Response URLs'. Despite these various naming conventions, there's little ambiguity in what we're referring to.
While the concept of a personalised URL maybe clear, there's definitely an industry misconception about how they actually work. Many believe that creating PURLs is not for the faint hearted — you either need to fork out mega-bucks for an all dancing cross-media software package or hand your campaign and dollars over to a 'PURL' ASP provider, who have the magical know-how to whip together some personalised web pages for your next marketing campaign. The reality is that creating personalised URLs is far from magic, it's actually surprisingly easy. In fact, you probably have some or all of the tools to create your own personalised landing pages right now, and you don't even know it.
If you've purchased Adobe Creative Suite 3 Design Premium, then you already have this capability. Adobe Dreamweaver offers a good level of database-integration through it's support for dynamic content. With Dreamweaver, you can define a database connection (or connections) and use the Bindings panel to bind the database fields to be displayed on your page and update values in the database. You can place dynamic content as a text string or insert it as an HTML attribute, for example, dynamic content can define an image, or a form field value.
When you 'bind' to a data source, Dreamweaver inserts a server-side script in the page's code instructing the server to transfer the data from the database to the page's HTML code when the page is requested by a browser — no coding is required! You can even preview the records one at a time from your database right from within Dreamweaver.
All you need to create your own dynamic, database-driven Web pages is Dreamweaver, a Web server (e.g. Microsoft IIS, Netscape Enterprise Server, Apache), a Web application framework (e.g. ASP.NET, ColdFusion, PHP) and a database (SQL, MySQL, other). If you don't have any of this and don't have a clue what I'm talking about, then there are a mountain of Web-hosting providers, who, for around $50 a year, will sell you a domain name, 5GB of storage, a database and host your Web site on a server which supports a selection of application frameworks.
So, it's really that easy. Now, let's talk about those personalised URLs. Personalised URLs or 'PURLs' can't be created with using Dreamweaver or any other HTML authoring software for that matter. Let me explain why.
When you create a dynamic webpage, you have to define a variable for the page to identify which record you are requesting from the database. A common method of doing this is to include a variable parameter in the URL, for example: http://www.mycampaign.com/landing.aspx?id=Eliot.Harper. In this case, the variable 'Eliot.Harper' is passed to the Web server to display defined fields for that database record.
The problem with this approach is that the URL is not very 'friendly'. Therefore, we need to build another layer between the dynamic Web page and the end-client to redirect a 'friendly' URL to the actual URL. For example, redirect www.mycampaign.com/Eliot.Harper to http://www.mycampaign.com/landing.aspx?id=Eliot.Harper. As it turns out, this is achieved using a similar technique to the alternate meaning of PURL (Persistent Uniform Resource Locator), although PURL in this context is intended for library cataloging and document applications, where long-term access to information is required through URLs which don't change.
If you (or your hosting provider) use Apache as your web server, then you're in luck. Apache has a mod_rewrite function that enables you to create highly customised rewrite scripts for your webpages. All you need to do is create a rerwite script in your site root and name the file '.htaccess'. There's a good tutorial on this creating .htaccess file rewrites on HTMLSource.
For IIS users, there's no need to despair. Helicon Tech have written ISAPI_Rewrite; an identical utility to Apache's mod_rewrite. You can even move configurations from Apache to IIS and vice versa just by copying .htaccess files. Helicon Tech offer a freeware and full licenced version of ISAPI_Rewrite on their website.
In summary, PURL is not a magical technology — it's nothing more than a marketing buzzword. If you just need to create PURLs for a marketing campaign, then open your Dreamweaver user guide and give it a go. You certainly don't need fancy software or an ASP provider to make them for you. However, if you plan to use PURLs in the context of cross-media direct marketing campaigns, then you really need to look for a solution which will allow you to create a common set of business rules and data source for deploying an integrated direct marketing campaign across both online and offline media. If a software vendor or ASP provider promises you PURLs, find out what they really mean and what you're really getting for your dollar.
Posted on Thursday, 10 January 2008 at 1:38 PM | TrackBack: http://www.veedeepee.com/cgi-bin/mt-tb.cgi/76