itch.io

I don't know if the iframe URL is likely to change, but one thing you can do is redirect the user to a domain you control.  You upload a single HTML file to Itch, which contains some Javascript that redirects to the URL where your game is actually hosted.  You can choose to change only the iframe URL, in which case the game will still be embedded in your Itch page, or you can redirect the whole page when the user clicks the Play button.

One recent nuisance is that Safari has started deleting sites' saved data if they're not used for a week (for "privacy").  There may be additional restrictions on iframes in Safari and other browsers—I vaguely remember something about that, because of them being used for cross-site tracking.  To avoid all this, I'm moving saved games to the server, and I'm working on a system which will provide one-click sign-up with no personal data collection.  There's no reason why I shouldn't make it available to other people too, once it's done, so if you'd be interested in this route let me know and I'll keep you updated.

Every year, the villagers of Greymarsh appease a dragon by choosing a young woman as a sacrifice, and leaving her handcuffed at the top of a hill. After the dragon comes, the girl is gone, and the handcuffs are open on the ground. Everyone knows that part of the story of St George. So... the dragon has a key and turns it with its claws? That doesn’t make sense.

George needs to solve the mystery, and quickly, because his old friend the princess is this year's sacrifice.

This visual novel has 26 possible endings.  See if you can help George out by playing the game here.

I don't know why that would be, assuming you've cleared your cache and everything.  I haven't used Unity analytics.  What happens if you change it to a completely different https URL?  Do you get the new URL, but with http instead of https?  Do you still get the old URL?  Or does it actually work and you get the new URL with https?

Yes, what's really needed is for Itch to provide a signed token giving the user's account ID (and possibly other details if the user agrees to share them).  I know there is a way to use such a token with Firebase and probably there is with PlayFab too.

A related problem is that there is no way for an HTML game to know if the user has paid.  I will soon be uploading a new version of Gwen which will be chargeable after a short taster.  It interfaces with PayPal entirely on its own because while I could set the game page to accept payments, there is no way for the game to be notified of them.

I don't think mixed content refers to CORS at all.  It's saying that you're loading an insecure resource (http://...) from a secure page (https://...).  That makes sense actually.  Itch serves everything from https so you'll need to load your analytics script from a secure server as well.

(The reason for the error, I imagine, is that otherwise the user is misled about the level of security on the page.  It appears to be secure, but in fact it could be attacked by tampering with the insecure script.)

Do you get any errors on the browser console?

You can use Firebase (and they have a free tier to get started) but you won't have the benefit of integration with itch.io's login system.  Users will have to create a new account, specifically for your game.

CORS is a way for a server to say what web requests it is prepared to accept from other sites.  It's difficult to know what itch could do to foul this up, since itch has no control over your server.  However, if you hosted your game on your own server, there would be no need for CORS.  Cross-Origin Resource Sharing only applies when the request is cross-origin, and it is not if the game and the analytics service are hosted in the same place.

There are a couple of traps with CORS.  The first is that for some types of request, CORS has to be explicitly requested by the code running on the browser.  The second is that a CORS request is split into two, with an initial "preflight" request being used to check for the presence of the CORS headers.  This is done with the HTTP OPTIONS method, so you should make sure your server is sending the CORS headers in response to OPTIONS as well as GET/POST.