Title: Using in-house/custom Analytics causes JavaScript Errors
Last modified: May 30, 2020

---

# Using in-house/custom Analytics causes JavaScript Errors

 *  Resolved [macgeekgab](https://wordpress.org/support/users/macobserver/)
 * (@macobserver)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/)
 * Using Google analytics (or, indeed, any of the “published” analytics types) works
   fine.
 * But it is also possible to use your own, in-house analytics by putting a blank
   space in the “Type” field. The problem is, that puts a blank “type” entry in 
   the opening tag:
 * `<amp-analytics id="123456789" type class="i-amphtml-layout-fixed i-amphtml-layout-
   size-defined" style="width:1px;height:1px;" i-amphtml-layout="fixed">`
 * And the problem with _that_ is by simply having `type` in there at all, it’s 
   parsed as though an external vendor’s transport settings are there, meaning if
   you add a “transport” tag (as you would want to do with your own in-house analytics),
   it throws an AmpAnalytics javascript error: “inline or remote config should not
   overwrite vendor transport settings”.
 * My suggestion: if “Type” is left blank on the config screen, let it be a valid
   submission and then, in those cases, don’t add “type” to the script call at all.
   This is consistent with the [AMP developers’ guidelines](https://github.com/ampproject/amphtml/issues/7096).
 * Thanks!

Viewing 9 replies - 1 through 9 (of 9 total)

 *  Thread Starter [macgeekgab](https://wordpress.org/support/users/macobserver/)
 * (@macobserver)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12915128)
 * For example, this code works 100% fine, and tracks 100% fine, except the plugin
   is adding that `type` field (as above) which throws the error.
 *     ```
       {
           "triggers": {
               "trackPageview": {
                   "on": "visible",
                   "request": "pageview"
               }
           },
           "transport": {
           	"beacon": false,
           	"xhrpost": false,
           	"image": true
           },
           "requests": {
               "base": "https://site.com/path/to/analytics/pixel.gif&rnd=${random}",
               "pageview": "${base}"
           }
       }
       ```
   
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12915839)
 * So the issue is that the “Type” input should be allowed to be empty, correct?
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12915892)
 * As an alternative to using the Analytics screen to provide this configuration,
   you can instead use plugin code to do the same:
 *     ```
       $print_inhouse_analytics = function () {
       	?>
       	<amp-analytics id="inHouseAnalytics">
       		<script type="application/json">
       			{
       				"triggers": {
       					"trackPageview": {
       						"on": "visible",
       						"request": "pageview"
       					}
       				},
       				"transport": {
       					"beacon": false,
       					"xhrpost": false,
       					"image": true
       				},
       				"requests": {
       					"base": "https://site.com/path/to/analytics/pixel.gif&rnd=${random}",
       					"pageview": "${base}"
       				}
       			}
       		</script>
       	</amp-analytics>
       	<?php
       };
   
       add_action( 'wp_footer', $print_inhouse_analytics );
   
       // For classic reader mode templates.
       add_action( 'amp_post_template_footer', $print_inhouse_analytics );
       ```
   
    -  This reply was modified 6 years ago by [Weston Ruter](https://wordpress.org/support/users/westonruter/).
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12915905)
 * Nevertheless, I’m seeing this as an issue when attempting to paste the `amp-analytics`
   tag onto [https://playground.amp.dev/](https://playground.amp.dev/)
 * > Inline or remote config should not overwrite vendor transport settings
 * The `transport` config is causing a problem here, but I don’t know why.
 * This appears rather to be a general AMP issue and not specific to the AMP plugin(
   other than the issue requiring a type), so therefore I recommend opening an issue
   on the AMP GitHub repo, as I’m not an expert on the `amp-analytics` component:
   [https://github.com/ampproject/amphtml/issues](https://github.com/ampproject/amphtml/issues)
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12915982)
 * I did open a PR to eliminate the `type` requirement: [https://github.com/ampproject/amp-wp/pull/4802](https://github.com/ampproject/amp-wp/pull/4802)
 *  Thread Starter [macgeekgab](https://wordpress.org/support/users/macobserver/)
 * (@macobserver)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12916252)
 * Thanks [@westonruter](https://wordpress.org/support/users/westonruter/).
 * I think this behavior is intentional to AMP (at least from my research this morning).
 * If you specify a `type` then it presumes you’re using a vendor definition and,
   when you’re using a vendor definition, the transport should be defined by the
   analytics vendor and not overridden by the publisher.
 * It would be possible, for example, for a vendor to only support GET requests,
   and then a publisher attempts to override that with a transport method that uses
   POST request and now thing are broken, hence the error. (Honestly I think it 
   should be a warning and not an error, but, hey, the internet exists for opinions,
   right? 🙂
 * With `type` absent, it knows you’re not using a vendor definition and `transport`
   is an acceptable thing to define.
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12916296)
 * I’m seeing the same console error both with and without the `type` attribute (
   including a `type` attribute that has no value).
 *  Thread Starter [macgeekgab](https://wordpress.org/support/users/macobserver/)
 * (@macobserver)
 * [6 years ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-12916683)
 * AHh, rats. That’ll teach me to believe what I intuit when reading the AMP developers
   talking on their threads. 😉
 *  Plugin Author [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * (@westonruter)
 * [5 years, 10 months ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-13219213)
 * FYI: The ability to omit the type will be part of v2.0 which is due out this 
   month.

Viewing 9 replies - 1 through 9 (of 9 total)

The topic ‘Using in-house/custom Analytics causes JavaScript Errors’ is closed to
new replies.

 * ![](https://ps.w.org/amp/assets/icon.svg?rev=2527602)
 * [AMP](https://wordpress.org/plugins/amp/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/amp/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/amp/)
 * [Active Topics](https://wordpress.org/support/plugin/amp/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/amp/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/amp/reviews/)

 * 9 replies
 * 2 participants
 * Last reply from: [Weston Ruter](https://wordpress.org/support/users/westonruter/)
 * Last activity: [5 years, 10 months ago](https://wordpress.org/support/topic/using-in-house-custom-analytics-causes-javascript-errors/#post-13219213)
 * Status: resolved