CrazyEgg plans allow for a certain number of active pages. See https://www.crazyegg.com/pricing for more info.

However, I don't see the option to choose which pages the code is placed on in the configuration settings on /admin/settings/crazyegg. I don't see this in the Readme either.

So, is this functionality available? If so, please document. If not, please consider adding it because the vast majority of Drupal sites would require this functionality in order to make use of CrazyEgg.

CommentFileSizeAuthor
#15 crazyegg-n1317938-15.interdiff.txt1.01 KBdamienmckenna
#15 crazyegg-n1317938-15.patch8.88 KBdamienmckenna
#14 crazy_egg_page_selection_1317938_14_7.x-1.x.patch8.88 KBaklump
#11 crazyegg_page_selection-1317938-11.patch8.52 KBfullerja
#10 crazyegg_page_selection.patch8.57 KBAnonymous (not verified)
#9 crazyegg_extended_final.patch8.91 KBk-mo
#8 crazyegg_extended.patch9.55 KBk-mo
#7 crazyegg_extended.patch8.54 KBk-mo
#7 snapshot2.png12.69 KBk-mo

Comments

yannisc’s picture

yannisc commented

You can select which pages to track from within the crazy egg dashboard. Having the tracking code installed on all pages doesn't do any harm other than the not needed loading of the javascript file.

I agree that being able to select on which pages to have the js injected would be a nice option.

noahlively’s picture

noahlively commented

Curious for some more feedback on this. I can certainly add the option, but is there really a compelling reason to?

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented
Title: Page Selection » Page Selection for performance
Version: 6.x-1.1 » 7.x-1.0

Including javascript on pages you don't care about increases the page load times unnecessarily. It would be better to only include it where strictly necessary.

philsward’s picture

philsward commented

Totally agree with greggles. Anywhere we can reduce the amount of stuff loaded on a page is a good thing.

I guess the question we need to ask is: "what's the impact of the loaded js?" If it's only a few lines of code injected at the bottom, I can see where there's no point in worrying about it. But, if its calling on a js file somewhere, that's one additional request per page that may not be necessary.

I personally haven't dove into the module to know one way or the other, just throwing out some thoughts.

philsward’s picture

philsward commented

Ok, I'm going to have to chalk this one up as a "must have"... When the crazyegg module is enabled, I see some fairly high "wait times" for many of the pages. Wait times of 1.5 - 3+ seconds (Basically waiting on a response from the server) which then leads to the actual download of the content, an additional 1 - 2.5 seconds. One of my views pages is taking over 7 seconds to load.

Disable the crazyegg module and my wait times drop to ~500ms with fully loaded page times between 1 - 2 seconds.

Based on what I'm seeing with the loading, I don't see anything specific pointing to the crazyegg module as the root cause, but If I disable the module, the pages load pretty quick. If I enable it, they slow down...

At this point, I'm left with the choice of "slow website" and collect data or "fast website" and just cancel my 30 day trial... I'm ramping up for my busy season and really can't afford to have key pages (that aren't being tracked by crazyegg) affected by slow load times.

---

Would it be worth the effort to also locally cache the .js?

k-mo’s picture

k-mo commented
StatusFileSize
new snapshot2.png12.69 KB
new crazyegg_extended.patch8.54 KB

Here is a patch, What it does:

  • Added 2 new permissions:
    • administer crazy egg pages
    • Access crazy egg settings

U should grant admins the following permission for full control:

  • administer crazy egg pages
  • Access crazy egg settings
  • administer crazy egg

If u want a certain role to be able to edit the page visibility give him the following permissions:

  • Access crazy egg settings
  • administer crazy egg pages

When u go to the crazyegg settings page (admin/config/system/crazyegg) u will see a new tab pages (works like block visibility). PHP filter can be added if wanted.
Feedback is welcome :)

Caching the file is possible but not included in this patch.

k-mo’s picture

k-mo commented
StatusFileSize
new crazyegg_extended.patch9.55 KB

Sorry typo, use this patch

k-mo’s picture

k-mo commented
StatusFileSize
new crazyegg_extended_final.patch8.91 KB

Final

Anonymous’s picture

Anonymous (not verified) commented
Issue summary: View changes
StatusFileSize
new crazyegg_page_selection.patch8.57 KB

Thanks, patch working ok for me, re-rolled patch with --relative.

fullerja’s picture

fullerja commented
StatusFileSize
new crazyegg_page_selection-1317938-11.patch8.52 KB

Patch in 9/10 works for me. Re-rolled to apply cleanly from module root, rather than modules directory

fullerja’s picture

fullerja commented
Status: Active » Reviewed & tested by the community
aklump’s picture

aklump commented

Please roll this patch into a 1.1 release or at least into the 7.x-1.x branch. I'd be happy to be a co-maintainer if you'd like.

aklump’s picture

aklump commented
StatusFileSize
new crazy_egg_page_selection_1317938_14_7.x-1.x.patch8.88 KB

Here is a patch against the 7.x-1.x branch 921fee5fe043b7dc72135b147a48998995516300. It's based on #11 but replaces drupal_add_js with #attached. Also I couldn't get #11 patch to work completely (1 hunk failed).

damienmckenna’s picture

damienmckenna
Location TN, USA
commented
Status: Reviewed & tested by the community » Needs review
StatusFileSize
new crazyegg-n1317938-15.patch8.88 KB
new crazyegg-n1317938-15.interdiff.txt1.01 KB

This fixes some coding standards mistakes.

kyletaylored’s picture

kyletaylored commented

Would it be worth reviewing this other ticket instead in favor of simplicity? For example, this issue adds two additional permissions. Is that really necessary? This is a fairly basic module that is replacing simple script embed, and just seems like a lot of overhead.

#2746447: Add page specific crazyegg listing

crazyegg’s picture

crazyegg commented

Thank you everybody for participating in this conversation.
However, as @kyletaylored correctly pointed out, the proposed solution would bring some overkill in this basic module, potentially leading to more issues and requiring more time for testing. So we're going to close this issue in favor of simpler solution suggested here: https://www.drupal.org/project/crazyegg/issues/2746447

Basic page-specific targeting was added to 7.x-1.x branch and will be officially released soon.

crazyegg’s picture

crazyegg commented
Status: Needs review » Closed (duplicate)