However projects might require inline js code. That code will execute before the deferred scripts – which might throw errors if the inline js code depends on libraries loaded via deferred script tags. Inline js code can be deferred like described on stackoverflow:
defer was introduced before async. Its execution starts after parsing is completely finished, but before the DOMContentLoaded event. It guarantees scripts will be executed in the order they appear in the HTML and will not block the parser.
As you know, Google Tag Manager is a tool that helps Online Marketing people to set up different kind of user interaction and conversion tracking without the help of developers. This separation of roles is beneficial for both developers (no tedious updates of click events) and marketing staff (no dependency to IT), however it only works if web developers prepare the website according to best practices.
This is a document for developers to understand better the life of an Online Marketing staff that is in charge of setting up and maintaining Google Tag Manager click events.
So what do Online Marketing people want to do with Google Tag Manager?
Here is a typical Google Tag Manager (GTM) use case:
GTM managers would like to set up the tracking of a range of goals in Google Analytics so that business can see interaction and conversion trends and online marketing can optimise their campaigns based on these signals.
GTM managers would like to set this up in Google Tag Manager so that online marketing and business can wire the conversion and interaction signals to their tags and update the wiring quickly and independently from website deployment schedules.
Typical GTM Troubles that Online Marketing Managers have
Below is a list of technical things that sometimes make the life of a GTM manager tough.
1) Link Clicks Triggers don’t fire
Sometimes, GMT managers set up click triggers for buttons and the click triggers don’t fire.
Here is an example of a typical click trigger on a submitt button on a page like /booking?date=2019-01-01:
This is the button:
Here is the markup of the button:
However the GTM manager notices that this click trigger doesn’t fire.
Note: The button click tracking does fire if GTM managers configures the trigger with the button text only (Click Text) == ‘SEND REQUEST’
In this specific case GTM managers would like to be able to use the parent element (button with type == submit) because this is less ambiguous and more bullet proof and simpler to set up and maintain.
Developers can help GTM managers having a simpler and more solid tracking setup by letting click events bubbling up in all cases.
2) No ids or distinguishing classes for important interaction elements
Currently important interaction elements such as buttons are not easily identifiable by business / online marketing staff when working with GTM.
An ID or a class name like “booking-date-time-step-continue” would simplify tracking setup.
Developers can help us simplify tracking by proactively setting ids or identifiable classes on important interaction elements.
3) No dataLayer information for transactional events
For some tracking cases GTM managers would like to measure more than a click. Example: a booking. In this case, it would be safer to get a signal from the backend that the booking has correctly been processed and is valid. This helps us prevent wrong trackings, for example if GTM managers would track the click on the ‘book now’ button, and there were form validation errors, GTM managers would still track a successful booking even if the website would not.
In order to help us track conversions correctly, you can use Google Tag Manager’s dataLayer.push() method.
In recent months, Google has increased efforts to automate many aspects of Google Ads, for example the display targeting. By doing so manual controls have been hidden or removed from Google Ads or default settings have been changed. This is not always in the best interest of the advertiser. Below I will collect cases where Google has started to take decisions over the head of the advertiser, and how advertisers can take back control.
Display Native Apps Exclusion
Many advertisers see little to no return on their ad spend invested on native app placements on the Google Display Network. Meanwhile, for Google it’s a fast growing market as more and more impressions are generated in native apps, mostly free-of-charge games.
In earlier, happier days, all in-app ads could be disabled by excluding the placement adsenseformobileapps.com . Google has phased this convenient possibility out in 2018. This ppchero.com article describes a workaround, but the setting has become harder to find and it’s not possible to exclude all native app placements as one anymore.
Display automatic targeting
If advertisers pay close attention they can see that by default, much of their display ad spend goes into something called Display Automated Targeting. This inflates media spend considerably which is especially misleading in Remarketing campaigns where an advertiser wants to target exclusively users that have visited the website before.
Sometimes a designer or a content editor wants images, videos or more advanced content sections such as image sliders to take the full width of the browser window or even the full screen (height and width).
Full width or full screen content has many advantages from a design point of view and is often used to show off great videos or images in the header of a page. Homepages often use a full screen hero section:
These full width elements normally have a background video or image which is set to cover all the available space, given a fixed height (for example 600px height).
This means, that depending on the browser windows size, a part of the background image will be cut off.
Background images are often centered. This means, that if the browser window is wider than the background image width, an equal part on the top and bottom of the background image will be “cut off” (= not visible). If the browser window is less wide than the background image, the background image will still try to cover the given height of the full-width section. For this, it has to sacrifice space in the horizontal dimension. The background image will therefore be cut off on the left and right, like, for example on this iphone X screen:
In the real world, users will come to see your beautiful full width section on many different screen and browser sizes. Therefore, many of them will never see all of your beautiful background picture, but always just parts of it.
That’s where safe areas come in. A safe area is the part of the image that will always* show, whatever the user’s device or screen size. Here is an example of the definition of a safe area for a specific website project:
Content editors and designers should be briefed accordingly, so that they know how to resize and crop their images, so that the important part of the image is inside the safe area. Safe area briefings for different full-width sections on the website are therefore often created by project managers and web programmers.
Here you are a template that you can download and use for your own purposes:
I hope I could explain the complexities of using full-width images in this articles. If you have any questions don’t hesitate to comment or write to me.
*In practice, of course, there will always be users that wont even see the safe area, because, for example, they use a very old Blackberry phone. However in web design its best practice to set a compatibility policy and then ignore devices and browsers outside of that policy for cost and efficiency reasons.
Older versions of django are currently not compatible with sqlite>3.25. More information here: https://code.djangoproject.com/ticket/29182 – Problems occur when trying to load a fixture via `./manage.py loaddata` or in some cases when using a database created in an old version of sqlite3 django throws a segmentation fault.