I’m not proud to say this, but saying it nonetheless. Before they kept records of win/loss and all the new stuff, back in the days of the olddddddd client. If you were losing you could just exit out of the client, and restart. It would skip giving you a loss. So you could only go for wins and keep it that way. Though that was back in the day when getting to the base pvp rank to #1 took around 40 trophies I believe. Which takes a lot more now. Though I do wish at least that if your game crashes on its own that it remembered the data from the previous fight, and you could just resume. As that stands even a crash gives you a loss.
As far as the game counting it as a win then subsequently counting it as a loss in the pvp history. A battle could be given a unique identifier and could only be counted as a win or a loss. And never as both. Giving it unique codes would also allow for the previous mention of a resume for the players game if there is a issue, crash, etc.
Not to mention recording these additional fight details, which small bits like this even across heavy play times the players in the game vs current storage limits would never consume really any space at all. And then you could additionally develop a subsystem like a janitor/guardian or like wow’s warden … that could scan for any strange gaming behavior and flag it for review.
As for the registration of players and these unique codes, varied across numerous data sets I did also use myself. Though my gaming backend was simply php/ruby driven that managed web applications or games I made in virtual worlds. Nothing like unity or GoW but it would still work very well. One of the last things I worked on was creating a process spooler in php, that micromanaged the connections, data, and what was being sent so that nothing bottlenecked or stepped over toes.
ehhh maybe I talk/type too much sometimes … lol