• Resolved djenk

    (@djenk)


    Maybe I’m missing something, but why can’t I manually enter my GA ID anymore? If that’s just the way it is now, I’ll be happy to switch to another GA plugin or the numerous other ways to have GA on my site, just want to know what’s up. Too bad, if that’s the case.

Viewing 15 replies - 1 through 15 (of 18 total)
  • It does look like it’s been removed. I’ve raised a support request with them since it’s not mentioned in the changelog

    Their docs How to Manually add a UA code only cover implementing a filter.
    Rather than doing that I actually just directly updated the site profile option via the cli
    wp option update monsterinsights_site_profile '{"manual":"UA-XXXXXXXX-X"}' --format=json

    I’d be curious about what alternatives people are looking at since we originally switched from Better Analytics to Monster Insights because the former was messing up the bounce measurement.

    I likewise specifically used MonsterInsights with manual UA codes. It looks like they removed that GUI with their update. I may switch to use a performance plugin named Perfmatters. The main advantage is Perfmatters will serve analytics.js locally thus removing an extra lookup as explained here: https://perfmatters.io/docs/local-analytics/. As a bonus Perfmatters actually integrates with MonsterInsights.

    I frequently build sites for clients who set up their own Google Analytics and just send me the UA code, which I would manually enter. The MonsterInsights docs do show how to add it manually, but another plugin is needed to do so? Weird, and a step back from how easy and useful this plugin is/was. I don’t know what other options are out there yet, but I’m adding this to the site I’m currently building:

    https://wordpress.org/plugins/ga-google-analytics/

    It allows for manually entering the GA ID. Not sure about other options/settings yet, but it’s also less “spammy” in the backend than MonsterInsights has become.

    • This reply was modified 9 months, 3 weeks ago by  djenk.

    Since nobody from the vendor seems to have popped in here, this is the support response I had from them

    Manual UA code insertion is removed in the current version apparently, though it’s something we’re looking at bringing back support for, and we should have an update for that in our next scheduled release which is coming out later in Feb. Our support team had to scramble and issue the doc post you referenced following that release (thankfully we have hooks as a workaround in the meantime).

    Long term, we’d recommending looking at auth, since a lot of the new features scheduled for this and next year require it to work, and even a lot of the current features (since we can’t do things like reports and such without it).

    So it looks like the functionality may be restored in a release later this month.

    Gal Baras

    (@galbaras)

    Message to the authors (Syed and team):

    This plugin now focuses a lot on the dashboard, to the point of being renamed to reflect that. Unfortunately, I suspect that long-time users, from back in the Yoast days, like it for the tracking features.

    Please do NOT require GA authentication and consider a clean separation between tracking features and reporting features, so that both types of users may benefit.

    Or split the plugin. I’m not too keen on extra code and will simply choose the tracking-only version.

    • This reply was modified 9 months ago by  Gal Baras. Reason: Clatification of who the message is for
    melhorwebtecnologia

    (@melhorwebtecnologia)

    I am moving to another solution. I just need to enter the manual code. Nothing else.

    chrisdavisberry

    (@chrisdavisberry)

    According to monsterinsights you can can manually add the code still but its lost all the user friendly appeal it had:

    https://www.monsterinsights.com/docs/how-to-manually-add-the-ua-tracking-code-to-monsterinsights/

    /**
     * Manually set a custom UA code in MonsterInsights.
     *
     * @param string $ua The current UA code.
     *
     * @return mixed
     */
    function monsterinsights_custom_manual_ua( $ua ) {
    	$ua = 'UA-123456-1';// Replace this with you UA code.
    	return $ua;
    }
    add_filter( 'monsterinsights_get_ua', 'monsterinsights_custom_manual_ua', 15 );

    Be sure to replace that UA code with your own Google Analytics UA code. If you aren’t sure what your UA code is, please see the first step in our guide: How to Fix Wrong Google Analytics Profile Selected in Settings.

    Hope that helps

    That filter does not actually add the code, it just makes the website act as if it is added, if the code is removed nothing is changed. Surely there must be a way to manually edit it someway, what database entries need to be edited?

    Actually I just found a good solution, since this bug appeared in a recent version only. Just install an older version of the plug-in, enter the UA code, then if desired, update to a recent version.

    Just found out about this new “feature” along with everyone else here. A lot of folks are willing to go to a lot of trouble to find a way around it, but it seems to me that if you don’t want to use all the dashboard features, it’s probably just easier to add the code manually in your header.php file. This new “feature” has just moved me to take that step and now I can bother with one less plugin 🙂

    @daverobinsonpw can you follow up with Support on the return of the manual ID for us? No more days left in February…

    @galbaras I’d recommend you and anyone else affected raise a support request yourself using https://www.monsterinsights.com/lite-support/ . Having more voices might mean that they’ll bump it up in priority. If anyone has a license with them then going via their priority support channel would probably add more weight as well.

    There’s no need for that. If we waste their time, that’s no good for anyone.

    They just need to be told about this forum thread.

    I’m disappointed to find the manual UA code entry removed. We’ll be looking for an alternative since the continued direction of the plugin has diverged from our long time interests in simple management of GA codes.

    Plugin Author chriscct7

    (@chriscct7)

    Hi there,
    We got pointed to this forum thread by a user who contacted our support.

    A couple things:

    1. We recently rewrote the entire settings panel from scratch in MonsterInsights 7.4, in an entirely new programming language (we moved to using Javascript based VueJS). As part of this, we took the opportunity to streamline the settings panel, make it faster, and try to make it less daunting for newer users.

    When rewriting a panel with the level of complexity required (from a programming side) to create a simplistic output (on a user side), there is always the chance that bugs will get introduced, or something will be forgotten. The todo checklist that we came up with at the start of the multi-month sprint that became the MonsterInsights 7.4 release had several hundred things we had to ensure got coded into (there’s a lot of possible combinations between base settings, addon settings, multisite handling, integrations, auth types, and so forth). And then you have to make it all work twice, for the lite and pro versions of our plugin.

    In doing so, we didn’t notice that between internal beta versions while we were trying to smooth out UX issues with the onboarding auth experience that the manual UA code link got removed. This wasn’t intended, I think actually someone else pointed out earlier we still fully support manual UA codes in core if you already had them there (there are also other cases where we show it, such as an auth causing an error, or after deauth for example), since all the UI is implemented, basically just the link to show it is missing. Notably in a release with hundreds of moving pieces, things can get lost. MonsterInsights 7.4 was running a dozen of our production sites (and those of volunteer beta testers) long before we shipped it out, but we don’t use manual UA on any of our sites, and we don’t use it generally speaking in testing, since auth is a technical requirement in order for us to be able to build the reporting area and a lot of our new lite and pro features that we’re also working on for releasing later this year

    We should also note, for a plugin of this scale, we pre-plan releases into groups. However, our internal ETAs are never perfect, as inevitably difficulties come up, and we have multiple teams working on multiple releases at any given point in time (as we speak we have a team working on wrapping up what will be MonsterInsights 7.5, as a different one is working on features for MonsterInsights 7.6).

    This is why we never, as a general rule of thumb, provide ETAs, because we don’t ship by a date, we ship in a release.

    2. The fix for the manual UA code link for non-authed sites is included in our next release, the MonsterInsights 7.5 release. As mentioned earlier, once we realized the bug, we rolled out a doc as a workaround that you can use in the meantime which you can find here. We’re hoping to get the 7.5 release out as quickly as possible, but we do have a couple of things that we need to get tested and signed off on first.

    3. As mentioned in our support forum policy, please note, we do not actively monitor these forums. We operate dozens of plugins, many of which are fortunate to be in the top 30 most installed plugin. The downside of this comes in the form of WordPress.org’s system for managing emails and support here on WordPress.org.

    For example, personally, I’m extremely involved in WordPress core. I work on the security team that sends out security fixes, and I work on the triage team which works on trying to keep the number of tickets reported to WordPress Core moving. As a result of this, I’m subscribed to notifications on quite literally thousands of threads, in addition to all the plugins, in addition to all of our plugins support tickets/reviews, and in addition any time someone mentions any one of many combinations of our plugin names on other people’s plugins.

    As much as email filters into custom inboxes helps for organizing some of those, for plugins, we find as a company, it is better to have a website only support policy. This allows our team of developers and trained support agents to have an easy ability (through the use of the same awesome HelpScout ticketing software we use for our Pro customers) to manage Lite support tickets.

    This also saves us from WordPress’s forum software, which has a lot of weird quirks such as burying a ticket after it gets a response back, so that no one ever sees it needs a reply. No offense to bbPress, but HelpScout is way better any day of the week.

    A lot of the plugins in the top 20 or even 50 offer zero or mine-as-well-be-zero-two-weeks-later support for their plugins. Our company firmly believes in customers first, and so for our Lite users who use our support, we provide 1 – 3 business day support, manned by dedicated support agents, from 9am to 5pm EST every day (most tickets get responded to and resolved faster than you’ll get the auto-responder back from other companies). And we do it for absolutely no charge, for any user of our plugin, even if they never (and most will never) pay us a dime for it. Contrast that other plugins you might use, like WooCommerce or Yoast which don’t offer free support at all (much less a turnaround time generally averaging a few hours with a satisfaction rate in the upper 90s consistently week-in-week-out). For us to be able to offer it, and at the service level we want to offer it, this is what works and scales for us, and that’s why our forum policy exists.

    You all are the reason we make MonsterInsights, every day. Feel free, if you ever desire, to reach out to us, to get help, tell us how we’re doing, or offer suggestions — just please do it through our website (we respond to each and every one we get).

    -Chris

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘No more manual entry of ID?’ is closed to new replies.