Shopify Expert Insights

Running AdSense on a responsive site doesn't have to be hard.

To promote a clean user experience, Google allows modification of the AdWords code (so long as it doesn't artificially inflate clicks or otherwise hurt the advertiser.) In the past, the only way to deal with responsive ads was to hide them in different layouts. If you have a simple single column website (like CalmingManatee) you can use the some simple in-line javascript to swap in the right format ad based on the site's width. In your AdSense dashboard, create one of each ad type, and drop in your publisher and ad IDs. It's pretty straightforward.

<script type="text/javascript"> 
adUnit   = document.getElementById("google-ads-1");
adWidth  = adUnit.offsetWidth;
google_ad_client = "YOUR_PUBLISHER_ID";
if ( adWidth >= 728 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width	= 728;
  google_ad_height 	= 90;
} else if ( adWidth >= 468 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 468;
  google_ad_height 	= 60;
} else if ( adWidth >= 336 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 336;
  google_ad_height 	= 280;
} else if ( adWidth >= 300 ) {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 300;
  google_ad_height 	= 250;
} else if ( adWidth >= 250 ) {
  google_ad_slot	= "YOUR_AD_ID";
  google_ad_width 	= 250;
  google_ad_height 	= 250;
} else {
  google_ad_slot 	= "YOUR_AD_ID";
  google_ad_width 	= 200;
  google_ad_height 	= 90;
} 
</script> 
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"></script>

	

Not all browsers are made equal.

Chrome, Firefox, and Safari showing differences in font rendering.

A website is just a set of instructions describing how a site should look. It's up to the browser to render it, and every browser renders things a little differently. For example, a common problem we've run in to is that Chrome and Firefox round percentages differently which can cause responsive layouts to break at different resolutions.

When someone finds an inconsistency, we ask them to give us the details of their environment and provide a screenshot (if possible) of the issue. Providing technical details doesn't have to be intimidating, we use Support Details to quickly and accurately get a clear picture of their environment. Once we have that, we can attempt to recreate the issue and address it.

No one wants to "submit" to you.

The default label for a button on a form is, and always has been, "Submit." That's a terrible label.

Submit doesn't provide me any context beyond the obvious: my information will be delivered somewhere, probably to someone. Even worse is the meaning of the word submit. It literally means "to give over or yield to the power or authority of another." Unless our form is for a rehab program, our user probably doesn't want to submit to anything.

Let's consider our newsletter. To sign up, you provide your email address and click a button. Since a button provides an action, it would make sense to use a verb. "Subscribe" would work. Subscribing is what we're directly doing. That's called a task-based label. It describes what we're doing, not why we're doing it.

To reinforce why we're subscribing, I could use a benefits-based label. Since I want you to sign up for this newsletter to improve your website, I could use "Improve My Website" as a button label. The label describes the benefit provided by clicking it, instead of the literal action. This might improve conversions. Benefits-based labels are uniquely suited to conversion forms because they remind the user why they're signing up.

A benefit based label isn't always appropriate. Consider the button to to post a comment on a photo. For that, we should just stick to the task. "Post Comment" would be best. Task-based labels are always better than "Submit," but benefits-based labels may increase conversions. The only thing left to do is split-test it and see.