Ari

Whatever route you take, get the details right, because a redirect done badly loses most of the benefit of doing it at all.

• Use a permanent redirect rather than a temporary one, so search engines transfer the ranking signals to the new address.
• Redirect path-for-path, not everything to the home page. A visitor following an old link to a specific article should land on that article, not on the front page. Wholesale redirection to the root is treated as a soft error by search engines and it is a bad experience.
• Cover both the bare domain and the www form, over both protocols. That is four combinations and people routinely configure two.
• Keep it running for years. Old links live a long time. Retiring the redirect after six months throws away the traffic you were trying to preserve.

One reason not to delay: browsers have been steadily increasing how loudly they mark plain HTTP, and search engines treat HTTPS as a positive signal.

So this is no longer only a security question. A site on plain HTTP looks broken to visitors in a way that is entirely outside your control, and it will get worse rather than better.

What people with a genuine commercial need actually do, none of which is prevention:

Show a version not worth stealing. Publish at display resolution with visible watermarking, and sell the clean high-resolution file. This is the standard approach across stock photography and it works because the public file is deliberately inadequate for the uses that matter.

Make attribution the point. Embed metadata, watermark discreetly, and treat wide sharing as marketing that carries your name.

Detect rather than prevent. Reverse image search and monitoring services find copies after the fact, which is when a copyright claim becomes possible. Enforcement is a legal process, not a technical one, and it is worth talking to somebody qualified about that if the value justifies it.

Put it behind authentication if it must not circulate. This does not stop a logged-in user copying it, and it does establish who had access, which is often what actually matters.

Worth passing the standard forwarding headers to the back end while you are in there — the original host, the original protocol and the client address.

Otherwise the application logs every request as coming from the proxy, generates links as if it were serving plain HTTP, and any rate limiting it does is applied to one address for all visitors.

Those three headers are the difference between an application that knows it is behind a proxy and one that is merely reachable through one.

If the actual goal is a private service rather than a private domain, the shape of the answer changes entirely and is much more achievable.

A virtual private network, a mesh network between your two machines, or an authenticated tunnel gives you a service only the two of you can reach, with no public name and nothing published anywhere. That is genuinely private in the way you were hoping the obscure domain would be.

Worth deciding which of the two you want, because they have almost nothing in common technically.

You are not missing anything obvious — granularity control in the standard reports of the current generation of analytics tools has been much weaker than in the previous one, and this is one of the most common complaints about the transition.

The behaviours worth knowing:

• Granularity is often inferred from the date range rather than chosen. Selecting a long range sometimes switches the chart to weekly or monthly automatically, and selecting a short one forces daily. So the lever is the range, not a granularity control.
• Exploration or custom report builders generally do expose the dimension directly — you add a week or month dimension and chart against that. This is the reliable route when the standard reports will not cooperate.
• Vendor documentation has at times stated plainly that only daily data is available in certain views. If you are in one of those views, no amount of hunting will help.

UI details in this area change frequently, so treat any specific instruction you find, including this one, as needing a check against the current interface.