Instead of focusing on the theories and speculations as to why CJ is going forward with what seems to many of us outsiders as insane, my primary focus has always been on the technical aspects. Hey, I’m an engineer, not a politician.
Commission Junction’s new FAQ remains vague on technical details, but it is at least a little less vague.
Here are some interesting points from the new document.
Can publishers still modify links?
One of the major sticking points and arguments against the LMI is that publishers give up control of their link content (image and link text) to the advertiser. That Javascript will allow the advertiser to change link text to something that breaks the publisher site’s logic and meaning. The updated FAQ should dispel this for good. (emphasis is mine)
With new JavaScript links, if an advertiser changes an image, the publisher page will automatically update with the change, unless the publisher has overridden the image in the query string.The publisher override will always take precedence over any updates the advertiser makes (this is exactly the same as is currently possible with legacy links).
With new JavaScript links, if an advertiser changes text in a text link, the publisher page will automatically update with the change unless the publisher has overridden the text in the query string. The publisher override will always take precedence over any updates the advertiser makes (this is NEW in that with Legacy text links those are hard-coded into the publisher site and couldn’t be dynamically updated).
With new JavaScript links, the publisher can override the destination URL in the query string, if this is allowed by the advertiser (this is exactly the same as is currently possible with Legacy links).
How CJ plans to allow publishers to make these overrides remains to be seen, but that pretty much kills the argument that advertisers shouldn’t have final control over what affiliates put on their websites.
What about browsers that don’t support JavaScript?
This one still makes me very uncomfortable. Here’s what CJ says about this.
Of the sample we collected from our network data, less than 1% of the users who click on Commission Junction based links have browsers that don’t support JavaScript. Of the 1% group, only 2% actually resulted in a sale. This is less than the number of users who don’t have cookies enabled. The correlation is similar – users whose browsers don’t support JavaScript or enable cookies rarely convert to sales.
“Browsers that don’t support JavaScript”? Is that User Agents that don’t have JavaScript support at all? The 1% number seems like that’s what they’re measuring, Otherwise, unless you’ve instrumented javascript tracking, you cannot accurately measure this number.
In that case, 1% would be the absolute baseline for lack of Javascript support. Add people disabling Javascript to that number and it adds up to larger numbers that people are reporting. For example, I would bet that some large corporations disable Javascript on all employees browsers as a security measure.
This is the one thing for which CJ cannot offer workarounds.
What about publishers who have a database driven site? Will they be required to make changes to my database?
This new item is interesting, and for the first time, starts to hint toward what’s behind the Javascript tags — POST requests instead of GET requests. Perhaps we can manufacture our own HTTP requests that implement the POST method (emphasis mine):
There will be a minor change in how these publishers manage redirects. Essentially, the changes will require that the AID and PID be passed to the Commission Junction servers in the HTTP header as a POST. This differs from the current method, where the AID and PID are passed to the Commission Junction servers in the URL as a GET.
This gets very technical quickly, but basically, they seem to be saying that if we keep affiliate links in our own database for incorporation into a website, and even for performing local redirects (e.g., for tracking), as long as we send the requests through a HTTP POST (not GET), we’ll be ok. My question: Even without employing any javascript?
The pertinent difference between a POST and GET is pretty simple. In a GET request, parameters are visibly incorporated into the URL. In a POST request, the parameters are buried in the invisible HTTP header. Creating post requests is more complicated. The only way to create a POST request through a browser (which we must do because we’re tracking users), it must be submitted through a form.
As for local redirects, I cannot come up with a good solution to redirect to another website with POST HTTP headers intact. Redirects are done by browsers using a GET request. I hope CJ has this one covered.
I’ll be covering the technical and performance aspects in detail as information becomes available.
