Adding Google Analytics to doc pages?

[jasnell]

See nodejs/node#6462 for context.

Original from @mikeal:

This adds the same analytics line to our documentation as we have on the rest of the website.

And my comment here:

hmm.. fwiw, I care that this would be executed when run locally.
Couldn't this be injected only when the docs are on the website.
-1 on this being here.

[luanmuniz]

I don't know if you guys have another ways to do that. But it will be a nice thing to know what parts of the documentation are more accessed because that way we can come to the conclusion that a specific module or a specific page is not well documented or that the people are using more or less a specific module and with that information the foundation can prioritise what is nice to work on. I don't know much about how you guys do things, so its just something that i thought. (And maybe the discussion about the local env its even better, that way we have even more data)

[phillipj]

@jasnell would a localhost check suffice?

if (window.location.hostname !== 'localhost') {
  // GA code inside here 
}

[jasnell]

Not so much. If I'm on a private network and want to throw the docs up on
an internal system I don't necessarily want it sending analytics data out
to Google and that data wouldn't be very valuable to us here. This should
only be injected when the docs are on the website.
On May 2, 2016 1:43 AM, "Phillip Johnsen" notifications@github.com wrote:

@jasnell https://github.com/jasnell would a localhost check suffice?

if (window.location.hostname !== 'localhost') {
// GA code inside here
}

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#709 (comment)

[jbergstroem]

Two server-side options using nginx. Both needs testing and I'd honestly like to avoid it seeing how we'd put a strain on our server(s), but lets get it in here for completeness.

• SSI

  <!--# include file="tracking.html" -->

• The sub module

  sub_filter  "</head>" "<script>$js stuff</script></head>";
  sub_filter_once on;
  sub_filter_type text/html;

[jbergstroem]

This should be possible injecting as part of the deploy process though?

[phillipj]

@jbergstroem we could possibly do a $NODE_ENV==production check when running the build process?

$ NODE_ENV=production npm run build

plus some changes in build.js and layout/*.hbs files.

[jbergstroem]

@phillipj should be feasible.

[phillipj]

Ohh I just realized this was a docs issue which has a different setup (in nodejs/node) than the website. Although $NODE_ENV could be a viable option anyway.

[rvagg]

So .. this can't be achieved directly out of this repo since this repo is completely unrelated to docs, they all come out of nodejs/node and we'd have to do something there, even if it's an SSI.

And, since whatever way this is going to be achieved we're going to be serving modified documents in all of the docs/ directories in release directories then how about we take this back to the node repo and implement a special make target to modify the docs for when they are being built to be uploaded as-is as opposed to being built for tarballs or built by end-users. Like make doc-with-analytics and put that in CI.

[rvagg]

Oh, sorry, I see that @phillipj's PR is attempting to do this over there. Closing this as I don't think it makes sense to be here.