<!--
Thanks for opening a PR! Your contribution is much appreciated.
To make sure your PR is handled as smoothly as possible we request that
you follow the checklist sections below.
Choose the right checklist for the change that you're making:
-->
## Documentation / Examples
- [x] Make sure the linting passes by running `pnpm build && pnpm lint`
- [x] The "examples guidelines" are followed from [our contributing
doc](https://github.com/vercel/next.js/blob/canary/contributing/examples/adding-examples.md)
First of all thanks for this amazing project and all the help you
provide with these examples.
It seems there is code duplication in this example. After some tests
locally seem to _document.js is not necessary for `gtag` to work
properly.
9d97a1e34a/examples/with-google-analytics/pages/_app.js (L30-L34)9d97a1e34a/examples/with-google-analytics/pages/_document.js (L13-L17)
I am aware of https://github.com/vercel/next.js/pull/40645 and I would
like to ask @dave-hay, @SukkaW and @ijjk to consider this is still
necessary. If so why then not move all content of the scripts from _app
to _document?
In any case, I am open to adding here some comments explaining what is
the reason for this code duplication if necessary.
<hr/>
Changes that come from https://github.com/vercel/next.js/pull/43897
1. The `event` hashChangeComplete should be removed since `/home` and
`/home/#section` is not new pageview, but just reference to the same
page.
If we go from /home to /home/#section (with a button click or a link for
example) this shouldn't trigger a new page visit on `gtag`.
For this reason, I think we should revert the changes from
https://github.com/vercel/next.js/pull/36079. If there is a better
argument of why this should stay I am also open to creating comments to
clarify this on the example since I don't think should be the default
behavior and not useful in most cases.
2. The `id="gtag-init"` was added with no context to the example from
https://github.com/vercel/next.js/pull/29530
If there is a reason for this id in the script to existing I am open to
adding a comment that clarifies this since in my experience is not
necessary at all.
Edit: Batching with https://github.com/vercel/next.js/pull/43897 as
recommended by
https://github.com/vercel/next.js/pull/43897#issuecomment-1344635000
---------
Co-authored-by: JJ Kasper <jj@jjsweb.site>
The with-google-analytics example had the "routeChangeComplete" event listener set up in components/Page.js, but that the event listener would only be set up if the user visited a page using that component. From the example, it's not clear if google analytics can be used without making every page use a component like components/Page.js. Someone following the example may make pages that don't use components/Page.js and fail to have page views reported, or feel compelled to force a shared component into their design unnecessarily, or might even make a mistake by making multiple different components like Page.js which each add a new "routeChangeComplete" event listener, causing page views to be over-reported when the user navigates between pages using the different components.
This PR moves the "routeChangeComplete" event listener into _app.js, where it's guaranteed to be executed for every page and is more obviously decoupled from page-layout-related components.
This PR also fixes a React warning about the lack of an onChange handler on an input tag, and removes the unnecessary implementation of `getInitialProps` in _document.js (the default implementation is inherited if not present, there's nothing this example needs to do with `getInitialProps` specifically, and the body of the method seems to have been based on an old version of next's internal implementation).
This PR also fixes the url being passed to google tag manager incorrectly. It looks like page_path should be used instead of page_location because the `url` value only has the path, not the full url with the domain name, etc. (https://developers.google.com/analytics/devguides/collection/gtagjs/pages)
