Forum Replies Created

Viewing 15 replies - 1 through 15 (of 42 total)
  • Thread Starter lonfirebrand

    (@lonfirebrand)

    Perfect.
    Thanks.
    You might want to put those methods in your documentation.

    Thread Starter lonfirebrand

    (@lonfirebrand)

    I ended up hiding the fields with JavaScript.

    Thread Starter lonfirebrand

    (@lonfirebrand)

    We want to capture UTM data and include campaign information in emails.
    While we have this information available in our analytics, the client wanted to see it in the form submissions.

    Sorry for the delay in the response.
    1) By default it is the entire viewable page
    2) Each percentage event fires independently. Normally you will see fairly standard distribution falling off towards the 100%.
    I’ve not seen a situation like this where there are more 75% than 50%.
    Is this a very short page? Perhaps with dynamic content loaded at the top that would push things down?

    I try to accomodate for all the Google Analytics implementation methods, but perhaps there’s something we’ve missed.
    How are you installing Google Analytics in your WordPress site?

    If you are running Google Tag Manager, this plugin isn’t really needed anymore because such reporting is now built in.

    This WordPress plugin just implements the ScrollDepth JavaScript. You can learn more about the specifics there.

    Sorry we missed this back when you posted.
    Are you using the gtag form of GA, or one of the older snippets?

    As part of my WordPress 5 testing, I just ran this with the gtag method on a site using Code Snippets.

    <?php
      add_action('wp_head', 'fb4_add_googleanalytics', 1);
    function fb4_add_googleanalytics() { ?>
      <!-- Global site tag (gtag.js) - Google Analytics -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=UA-********-x"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
    
      gtag('config', 'UA-********-x');
    </script>
    <?php
    }

    Again, sorry for long delay.

    I just tried it on my gtag test install (manually added snippet to theme) and it seems to be firing events.
    I AM seeing a weird warning from the current gtag code, but everything seems to be working.

    In your case, it looks like the wp_scroll_depth_head is firing and putting the initialization in there.
    Since we’re not getting an error on the jQuery( document ).ready() it would seem that jQuery is loaded in time for this be called.

    If you watch the Network tab, does the page try to load js/jquery-scrolldepth/jquery.scrolldepth.min.js ?

    Oh… are you logged in by chance when this error fires? It’s possible my check for is_admin is not correctly implemented.

    I did a little reading on Genesis Framework scripts and it’s very possible the theme doesn’t like the initialization in the <head>.

    If you’re comfortable editing code to test something, you could try changing the add_action("wp_head", "wp_scroll_depth_head"); (around line 187) with
    add_action("wp_footer", "wp_scroll_depth_head", 99);

    If that solves your issue, I don’t have a problem pushing it into the main release – most modern themes should be OK with that.

    Sorry for the delay.
    Is this first-time install of the plugin?
    How are you implementing Google Analytics?
    (Old _ga() snippet, Google Tag Manager, Universal Analytics, or the new gtag tracking snippet?)
    Are there other JavaScript errors earlier in the log that might be preventing scrollDepth from loading?

    Forum: Plugins
    In reply to: [WP Scroll Depth] GDPR?

    Updated the plugin with the new 4.9.6 privacy suggestion stuff.
    https://wordpress.org/plugins/wp-scroll-depth/

    But like I said, it just sends data to Google.
    I don’t see a global “visitor has consented to tracking” flag in WordPress yet.

    The link to /tools.php?wp-privacy-policy-guide=1 appears in the top of the privacy page editor in 4.9.6.
    And it seems to be working!

    Forum: Plugins
    In reply to: [WP Scroll Depth] GDPR?

    Sorry for the delay in responding.

    The WordPress plugin is based on [ScrollDepth](http://scrolldepth.parsnip.io/) JavaScript.
    I don’t see anyplace in the code that it creates a cookie.
    It simply sends sends Events to Google Analytics.
    If your audit system is flagging the Google Analytics cookie as not GDPR-compliant then you will want to review the GDPR information on consent for Google Analytics and decide how to manage Google Analytics.
    A [reasonable article](https://brianclifton.com/blog/2018/04/16/google-analytics-gdpr-and-consent/).

    If you plan to use Google Tag Manager to choose when to load the script, then you may want to switch to GTM’s built-in scroll tracking. (They have added basic scrolling as well as element visibility to GTM.)

    If you’d like to see the plugin directly support a consent switch, please let me know how you’d like that work.
    The user data tools in WordPress 4.9.6 don’t apply to this plugin: No data is associated with a user on the WordPress side of things. Google will probably associate those events with a persistent cookie.

    Sounds like we’ll be getting more data-related features in 5.0.

    Not sure I answered the question. Please let me know if there’s more we can do to help you with your GDPR plans.

    It looks like everything is loading.
    jQuery.scrollDepth() is defined and callable.

    The if you’re comfortable looking at the browser console, an easy way to see if the script is working is to go to Settings:ScrollDepth in the dashboard.
    Then in the “Event Handler” section just cut-and-paste the sample function into the edit box and save.
    Open a page and view the developer console as you scroll.
    The scrolling events should show up in the console.

    Ah… I see gtag.js
    This looks like a new implementation method for Google Analytics.
    I know the underlying scrolldepth JavaScript looks for Google Tag Manager, Universal Analytics, and “Classic” Google Analytics. I suspect this might be “none of the above.”

    I don’t think the issue is in the WordPress plugin, but with the new recommended script from Google.
    Let me check in with the folks that manage that code and see if they are aware of this issue.

    Thanks for the report.

    Plugin Author lonfirebrand

    (@lonfirebrand)

    Bummer.
    I’m adding some cleaner debug control and updating the documentation, but doesn’t help your issue.
    Google is recommending that people switch to Google Optimize. They haven’t officially deprecated Content Experiments yet, but also aren’t really supporting it right now.
    “Google Optimize is the free, preferred way to run experiments. Analytics Content Experiments remain available but are being deprecated in the future. Learn more about Optimize.”

    I’ll set up an experiment using GTM and see if I can track down the event issue. Everything seems to be firing in the right order, so not sure what’s failing yet.

    Thanks for your patience.

    Plugin Author lonfirebrand

    (@lonfirebrand)

    @omerida Is this a new issue (Just pushed out a small change last week) or is this just a new implementation that’s not working?

    Plugin Author lonfirebrand

    (@lonfirebrand)

    I incorporated you solution into version 3.0.2.
    Thanks, omerida.

    Plugin Author lonfirebrand

    (@lonfirebrand)

    Thanks for the heads-up.
    Yes – looks like uBlock (or other blocker) is preventing the tracking from initializing.
    I’ll update the code to make sure the debug is initialized. Ironically, debug features aren’t well tested. 🙂

Viewing 15 replies - 1 through 15 (of 42 total)