As an aside, and briefly glancing over this thread I don’t think it was mentioned here, but I have had Mailgun open analytics off for some time. The problem for me was not that it wasn’t tracking opens, but that, when members were getting emails sent to them for logging in, the link was prepended with “email.” so when clicked, it just 404’d.
That’s very strange, I don’t have any ideas at the moment 
Is your other site completely fine? Do they both share the same Mailgun account and domain or are those separate?
That’s from click tracking, not open tracking. Open tracking does not affect any links in the email, instead it injects a 1x1px image into the html version so that the loading can be tracked. Although for either to work you will need to have the relevant subdomain CNAME properly configured with your DNS provider.
Indeed, Sorry. That’s my mistake. I haven’t had to deal with that issue for a while now. You are right, it is click tracking. However, it is an issue. Is there any solution to it?
Did you follow those Mailgun instructions? Without knowing more details about where the 404 is coming from it’s difficult to know what any solution would be. If you don’t have a CNAME set up correctly the links would definitely fail though because the email.yourdomain.com clicks wouldn’t hit Mailgun’s servers for the redirect to function.
Yes. For sure. I will check again soon and report back.
Hi @Kevin
It’s a month ago I reported this. This is what has happened since:
The Open Rate numbers do come in, but they are very delayed — often about five days. It seems that my Ghost installation is somehow not pulling the data from Mailgun very often. Any idea how to fix this?
@Kevin Another quick update.
The last 5-7 days the open rate analytics have finally worked, as it is supposed to — meaning that the opening rate has been updated continuously throughout the day and not coming in with approximately five days delay. But as of today the open rate is not recording again.
I have made no changes at my end that would have either fixed it or caused the problem to occur again.
I updated to 4.0.1 on the day of release, but it was not that update that caused the opening rate to work — it came in later. I am still running 4.0.1 and have not changed any settings in Ghost or Mailgun since the update.
I don’t know if you have made any changes on your side, that you can connect to fixing the problem and now to recreating it again. But maybe this information can help you find a pattern.
Best,
Nic
I have a similiar case in the open rates.
I have the worker successfully running every 5 minutes, but it always seems to fetch 300 events and only 1 email. I can cross check with mailgun that there are unique opens that could be fetched.
INFO Worker for job "email-analytics-fetch-latest" online
INFO Worker for job email-analytics-fetch-latest sent a message: Fetched 300 events and aggregated stats for 1 emails in 15273ms
INFO Worker for job email-analytics-fetch-latest sent a message: done
INFO Worker for job "email-analytics-fetch-latest" online
Does Ghost fetch individual emails from the Mailgun log and cross check them against the member list?
I am trying to understand from this thread whether it is indeed a fixed problem, or there is still an issue. In my case Mailgun is correctly tracking opens, but Ghost is reporting 0%. Like the OP, I have a non-standard CNAME for MG: email.mg.debugmsg.io.
Is there something I need to do in my Ghost setup to make this work?
This particular instance is running Ghost 4.0.0 (I am nervous to update based on other threads).
The Ghost logs actually reveal this:
[2021-04-18 09:54:31] INFO Worker for job "email-analytics-fetch-latest" online
[2021-04-18 09:54:33] INFO Capturing error for worker during execution of job: email-analytics-fetch-latest
[2021-04-18 09:54:33] ERROR
MESSAGE: Invalid private key
Error: Invalid private key
at IncomingMessage.<anonymous> (/var/www/ghost/versions/4.0.0/node_modules/mailgun-js/lib/request.js:327:17)
at IncomingMessage.emit (events.js:327:22)
at endReadableNT (internal/streams/readable.js:1327:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21)
[2021-04-18 09:54:33] INFO Capturing error for worker during execution of job: email-analytics-fetch-latest
[2021-04-18 09:54:33] ERROR
MESSAGE: Worker for job "email-analytics-fetch-latest" exited with code 1
Error: Worker for job "email-analytics-fetch-latest" exited with code 1
at Worker.<anonymous> (/var/www/ghost/versions/4.0.0/node_modules/bree/lib/index.js:385:40)
at Worker.emit (events.js:315:20)
at Worker.EventEmitter.emit (domain.js:467:12)
at Worker.[kOnExit] (internal/worker.js:240:10)
at Worker.<computed>.onexit (internal/worker.js:174:20)Apparently the “private key” and the sending key are different. It is important to use an API key, as noted in this newer thread: