When Worlds Collide Pt. 3: Stick to the Scripts!

by Ryan Miller
on September 16, 2015

In part two of our discussion on the connection between web development and marketing, I had briefly touched upon my history with Javascript. When I first met this beautiful siren, it was love at first script. Then I learned the hard way just how much it can destroy page speed and website load times, and I felt a little differently.

But at the end of the day, I’ve still got nothing but love for my favorite front-end development framework. Javascript is not only crucial to just about every website — literally, it brings static pages to life — but it also has significant marketing applications. And, whether or not a given marketers is remotely interested in AJAX or dynamically loading page content, any true blue marketer should take at least a beginner’s interest in it.


The Javascript web beacon is what allows Google Analytics to feed this data to you.

Most SEOs first encounter Javascript when they place their Google Analytics tracking code into their websites. When webmasters create a new property on Analytics, Google generates a tracking code that requests the master analytics script (called ga.js) from a Google server whenever the page is viewed. This script then tracks and analyzes such useful information as page views, new vs. returning visitors, and referral sources for the webmaster to view.

There’s nothing complicated about this, and I would wager that those unfamiliar with Javascript rarely go any further than copying and pasting the Analytics tracking code. But what if they want to track the rate, frequency and value of ecommerce conversions? What if they want to run multiple tracking objects, or there is a conflict between these objects and the one that ga.js creates?

Better brush up on your Javascript, SEOs. The analytics that Google provides only goes so far. If you want to get serious about analyzing sessions and optimizing conversions, you’re going to have to customize some of the tracking script’s functionalities, including:

  • Event tracking (submissions, newsletter signups, etc.)
  • Campaign tracking (paid search, organic search, link referrals, social network referrals, email referrals, etc.)
  • Customizing the names, permissions and expiatory times of the cookies that ga creates
  • Integrating analytics with developer plugins
  • Tracking user interactions with content (e.g. AJAX) that is dynamically loaded
  • Almost anything related to ecommerce (from conversion tracking to product IDs, skus and brand manufacturers)

Webmastering/Technical SEO

Analytics is only the tip of the iceberg, and it would be an understatement to note that Javascript has had quite the tumultuous relationship with SEO.

First and foremost, there is the issue of site speed. Why site speed matters is self-evident (user experience, DUH!), and herein Javascript can be problematic because browsers can only parse a handful of external scripts at the same time. Simply put, too many scripts = too many server requests = a website that’s slow to load.

Given the almost universal necessity of inserting at least one script in a given web document, there are practical solutions to this (inlining, compressing, minifying, caching, etc.). I won’t discuss that right now because I want to get to something even more significant: search engines can’t even crawl Javascript!

This is your web page. It's full of Javascript... and search engine spiders are getting angry!
This is your web page. It’s full of Javascript… and search engine spiders are getting angry!

SEO is best defined by its relationship with search engines, for the whole job revolves around making sure search engines crawl, index and rank the SEO’s content. And, as anyone who has read 3 pages of a “Beginner’s Guide to SEO” PDF will tell you, search engines only crawl, index and rank one thing: HTML.

Obviously, most of a webpage’s content is going to be HTML, so seeing the problem in this takes a little more nuance than a first glance might reveal. One obvious situation that could turn out problematic is HTML can only be displayed when a Javascript event triggers it. For example: when a user clicks a button or hovers over something.

Another problem — which TM34 actually experienced in its young and more vulnerable years — is lazy loading. Lazy loading is the practice of loading images only when the browser’s viewport comes across them (that is, when a user scrolls to them). Search engine spiders don’t “scroll” like a human user would. So, if they cannot access these images on the initial attempt, the images might as well not exist on the search engine’s index.

So what are the solutions to these problems (assuming Javascript-rendered content is useful and it’s important that you index it)? Well, at the risk of being painfully anticlimactic, there are too many to list here. In fact, the Google Developers community has a plethora of articles on this topic alone (e.g. this one here, which I’ve recently been implementing).

But be forewarned: oftentimes what’s good for front-end development isn’t so great for SEO. Think the AJAX Fragment Specification will work? It’s probably a best practice to follow, but in my experience, users hate ugly URL structures. Maybe you’ll try using the <noscript> HTML tag, but beware of its extensive history with black hat SEO tactics such as cloaking. If that’s the route you choose to take, good luck convincing Google you’re not up to any funny business.

The point is that SEO-friendly use of Javascript requires an extensive background in BOTH the former AND the latter. Few web developers are well-versed in the nuances of getting content crawled and indexed, and probably even less SEOs know how to use Javascript in a way that’s optimal for user experience.

Adwords Scripts

At this point you’re probably sick of hearing about all the problems that Javascript causes, so let’s switch gears and talk about the opportunities it presents. First on the list: Adwords scripts.

Any marketer that has managed a composite of over $10k in monthly Adwords budgets can attest to the time invested in merely planning, analyzing and reporting their campaigns. If that’s the story, then it’s only because a) they haven’t heard of Adwords scripts, or b) they have heard of Adwords scripts, but don’t know how to program in Javascript.

This is a case in point on how web development has a direct affect on marketing. For, with just a few lines of Javascript, paid search marketers can not only automate their analysis of cost, quality score, etc. They can also programmatically bid on keywords and create ads/ad groups dynamically.

This seldom-used feature can be found in the backend of any Adwords account right under the “Bulk operations” tab:

Programming Adwords Scripts With Javascript

If you take a look at the Google Developers guide on creating Adwords scripts, they give you one to get started. Here’s what it looks like:

function main() {
var keywords = AdWordsApp.keywords()
.orderBy("Impressions DESC")

while (keywords.hasNext()) {
var keyword = keywords.next();
Logger.log(keyword.getText() + ": " +

It probably looks confusing, but all this script really does is order data within a certain set of parameters:

  • This script orders keywords
  • It orders them in descending order by the number of impressions they received
  • The timeframe of the ordering is yesterday
  • It retrieves only the top 10 impression-earning keywords

Google also provides the logger output Logger.log, but that’s not necessary to include unless you want to debug your script.

Well, that handy little script can make ordering your ad data a little easier, but is these menial functions are only the tip of the iceberg. You can also program scripts to automate your bidding based on such parameters as target position, bid increase/decrease %, and maximum/minimum bidding limits.

But the coolest feature (at least in my humble opinion) is the ability to actually change the ad creative itself. Oftentimes, I’ve used Javascript a la the jQuery library to dynamically change text on an HTML document, like so:


Well, the same logic can apply to your Adwords ads. Let’s say you’re trying to market your addiction treatment center. If you created a generic ad titled “Top-Rated Drug Rehab,” you could change that text to “Top-Rated Florida Drug Rehab” when “Florida drug rehab” is the specific search query. This way, your ad is always more relevant to the search, and relevance = clicks = conversions.


Retargeting is another case in point on the relationship between Javascript and marketing. This little gem — known by few but experienced by all — is a form of digital media buying that targets audiences who have visited a website but have not converted (that is, have not taken action to buy the site’s product or service).

Normally, setting up a retargeting campaign is as simple as setting up the Google Analytics code. You simply copy and paste the script that is given to you. In this case, you get a script from your ad server or intermediary. Here’s what the Facebook retargeting script looks like, for instance:

Facebook retargeting Javascript
The blacked out pieces are the campaign IDs, which (for obvious reasons) I cannot reveal.

So you copy, you paste and you watch your ROI quadruple, right? In 9 out of 10 cases, yes, retargeting is that simple. But what if you wanted to do something more? This bare bones script doesn’t account for conversions, so what if you only wanted to retarget visitors that didn’t convert?

Or, what if you wanted to retarget visitors whose conversion value was under a certain amount? What if you wanted to create a custom audience of visitors who displayed likely buying tendencies? What if you wanted to retarget multiple custom audiences on the same page on the same site? Can you just add a dozen different scripts on a single page?

Retargeting platforms tend to be pretty user-friendly, but it never hurts to have a little JavaScript knowledge if and when you encounter issues such as these. Whether you’re grappling with a decrease in site speed, debugging a script that’s not firing or attempting to customize your campaign, a solid foundation in it will always trump the user forums and product support.

Like This Article? You'll Love Our Work.