Clarify that 404 analytics is only available on Read the Docs for Business

[thibaudcolas]

It would be nice to have this documented, as otherwise it’s not clear what to expect from the platform. I was hoping to use this data as part of designing a custom 404 page for my project, but it looks like it’s a Business feature only. I figured this out based on #9131.

---

📚 Documentation previews 📚

• User's documentation (docs): https://docs--10967.org.readthedocs.build/en/10967/

• Developer's documentation (dev): https://dev--10967.org.readthedocs.build/en/10967/

[agjohnson]

Thanks for the addition @thibaudcolas!

I actually don't know if this is meant to just be a feature of our commercial hosting. It's also likely that this is still a beta feature that we haven't rolled out to all projects yet. We generally start features off protected behind a feature flag, especially features that could cause unexpected load (and our 404 handling is expensive, for some design reasons).

@stsewd @ericholscher do you remember the context around the change in #9131?

[thibaudcolas]

Thanks for looking into this @agjohnson. Well if this was meant to be more widely-available eventually I’d be very happy of course :) Do let me know if you need an extra beta tester.

[stsewd]

@stsewd @ericholscher do you remember the context around the change in #9131?

I think this was due to the amount of 404s on .org, it was a lot and slowing down the DB.

So It's correct to document that tracking 404s is just for RTD for Business.

[ericholscher]

Yea, there's a ton of crawlers on .org sites unfortunately. We can likely enable it with the feature flag though for a specific project, I think.

[agjohnson]

@thibaudcolas which project(s) are you needing this feature on?

[thibaudcolas]

@agjohnson I was looking for our 404s for Wagtail: https://readthedocs.org/projects/wagtail/.

If you’d be interested in the use case, this is in the context of wagtail/wagtail#11055 – 404s when someone looks at release notes for a specific version, and uses the version switcher to go to another version. For example if I’m on our 5.2 release page and use the version switcher to view 5.1 (404).

[humitos]

404s when someone looks at release notes for a specific version, and uses the version switcher to go to another version.
For example if I’m on our 5.2 release page and use the version switcher to view 5.1 (404).

Interesting...

Currently, you are using the default flyout that keeps the pagename when clicking on a different version from it. However, the flyout from the new beta addons changed this behavior and always go to the home page of the clicked version.

We talked about this in readthedocs/addons#211 and #10102

In you opinion, would it better UX to go to the home page of version 5.2 (https://docs.wagtail.org/en/v5.1.3/) when clicking on 5.1 from the flyout menu?

[thibaudcolas]

Good question @humitos. From my perspective I think what would matter most is consistency / meeting user’s expectations for version switchers. With the current design at least, I’d expect the page to preserved. I think that might be because it sits one layer "above" the rest of the site – if it was part of our site’s normal content and had the same livery, then perhaps I’d expect and find it clearer for it to go to the homepage.

As far as UX issues the bigger one for us I think is that we don’t use a custom 404 page. The default 404 UI looks very different to our site, so it’s very jarring, and I suspect our users are thrown off by not seeing the site’s navigation. If we had the version switcher head to a 404, I think it’d be much less of a problem if the site’s navigation and search were present.