Analytics mysteriously flatlined [#2894937]

I have two sites that mysteriously flatlined on analytics, one starting on June 9th, which was not noticed until today (July 14). Logging in and reviewing the tag manager interface did not show any obvious misconfigurations. I made a trivial change in the settings (switching from add snippet for "all roles except the selected" without any selected, to "Only the selected roles" with all selected) allowed the tag manager code to come back and start working. I changed the option back to it's prior state, and it also seemed to continue working.

I know there is a newer release of the module available and I am filing this for 7.x-1.1. I just wanted to determine if this was a known issue (I've reviewed the issue queue, and have not seen any similar items).

Also, it's not entirely accurate to say it flatlined, there was a "dribble" of users as our analytics person says.

Comments

Comment #1

14 July 2017 at 17:43

bburg created an issue. See original summary.

Comment #2

solotandem CreditAttribution: solotandem commented 14 July 2017 at 19:29

Category:

Bug report

» Support request

Here's what I understand from what you wrote in the issue summary:
You have described symptoms ("flatlined on analytics") and actions you took ("trivial change in the settings") after which things worked again. You conclude your action "allowed the tag manager code to come back and start working", but have not explained why the symptoms existed nor why the action resolved them. Without the "why", you have not demonstrated the symptom is due to a bug in this project. Does that make sense?

Can you reproduce this on the 1.1 release or latest dev release? What other pieces are there to the puzzle? Caches, varnish, analytics, other modules? Was anything else changed before the symptom occurred?

Also, you refer to problem with analytics. Is the google tag snippet on the page? If so, then is the issue downstream of this module, either with Google or the analytics module?

Comment #3

bburg

he/him

Washington D.C.

CreditAttribution: bburg at Forum One commented 14 July 2017 at 19:51

Google tag snippet was not on the page.

I'm trying to reproduce the problem, which I'm not yet able to do. I've only described what I experienced on the production site. So I don't know why or how this happened yet.

Varnish is running, but the site in question handles all authenticated traffic, which bypasses varnish. We do use memcache as an alternative back-end cache, so there could be something there. There are plenty of other modules on the site, and I would consider it a more complex site than the rest of the sites on which I've worked.

Comment #4

darby3 CreditAttribution: darby3 commented 14 July 2017 at 21:08

This looks almost exactly like an issue I've just run in to; our team just noticed today (weird coincidence!) that the Tag snippet was not firing. I'm fairly certain I can confirm that the "trivial change" noted above has gotten GTM back up and running as expected, though the situation is still being investigated.

Comment #5

joelpittet

English

Vancouver

CreditAttribution: joelpittet at The University of British Columbia commented 14 July 2017 at 23:18

Ran into this as well, I updated to -dev, disabled and renabled the module and turned off the compact and separate file features and it seems to be back up from my point of view. That is strange, didn't debug deep into the cause.

Comment #6

bburg

he/him

Washington D.C.

CreditAttribution: bburg at Forum One commented 15 July 2017 at 01:38

I'm trying to debug this. I have a dev site that is running with the problem now.

The issue seems to be happening in the status check. drupal_get_http_header('status'); is returning NULL for some reason. Which causes this to fail:

      $status = drupal_get_http_header('status');
      $satisfied = strpos($statuses, $status) !== FALSE;
      $satisfied = ($toggle == GOOGLE_TAG_EXCLUDE_LISTED) ? !$satisfied : $satisfied;

Since this is a remote dev site, and I don't know how to hook into xdebug remotely, debugging is slow (I should look into that). But at least that is a lead.

Comment #7

bburg

he/him

Washington D.C.

CreditAttribution: bburg at Forum One commented 15 July 2017 at 01:47

The output of

drupal_get_http_header();

 ( 'content-type' => 'text/html; charset=utf-8', 'content-language' => 'en', 'x-frame-options' => 'SAMEORIGIN', )

but even then, I'm also getting NULL on the status locally, where the tag manager code is appearing.

Comment #8

bburg

he/him

Washington D.C.

CreditAttribution: bburg at Forum One commented 15 July 2017 at 01:55

Nevermind, I think that status was a red herring. NULL is not in excluded values, so that check gets flipped. Also, my dev site seems to be outputting the tag manager code now. So I don't know how to replicate it...

I feel validated to see other people are reporting similar issues. We have at least two projects where we've lost a month of data, so this is pretty huge.

Comment #9

bburg

he/him

Washington D.C.

CreditAttribution: bburg at Forum One commented 15 July 2017 at 03:02

Category:

Support request

» Bug report

Ok, I think I have a hunch on what's going on. I've had random issues in the past with this module, but never followed up until now, and this explains all of them.

When you configure this module at /admin/config/system/google_tag, you can select "Include the snippet as a file" under the advanced tab. However, the results of submitting the admin form with this checked or not are the same, a template javascript file is filled in with values that apply to the current configuration, and saved to "public://js/google_tag.$type.js", it actually saves three files,

google_tag.data_layer.js
google_tag.noscript.js
google_tag.script.js

In the case of using an included file, it will add an external reference, for inline, this module will grap the contents of the file with file_get_contents, and include the content that way.

The problem is the save location. public://js/ is the location where Drupal stores aggregated javascript files. This directory is cleaned out every 30 days. See https://drupal.stackexchange.com/a/66044/75558, https://api.drupal.org/api/drupal/includes%21common.inc/function/drupal_.... Which is done to prevent cached pages, referencing old, aggregated js from breaking, but the files generated by this module will be cleaned up as well. So basically, this will break at least every 30 days.