Calculation of FP % is incorrect

[+capoaira]

The calculation of the Fav-% is incorrect on the result page and cache listing:

This cache has about 1000 logs and therefore a PM-fav-% of about 30%

Please fix it, the Fav % are the only real tool for quality cache

Edited January 23, 2023 by Bl4ckH4wkGER

[+barefootjeff]

1 hour ago, BendSinister said:

suspect it has something to do with non-PMO status, as my PMO caches have the expected percentages.

(If this is some sort of *deliberate* exclusion of non-PMO caches it'd be wise to indicate that instead, as the current phrasing is basically tens of thousands of lies all over the site LOL.)

 

I only have one PMO cache and that's also showing 0% in spite of having 13 FPs from 87 finds:

 

 

The same thing is happening on the cache page:

 

[+simon_cornelus]

I Think it's a bug indeed.

I have one PMO cache that's archived with the same behavior and some other caches, all seem to have "0% Favorites/Premium logs" on the list and "<1% Favorites/Premium Logs" on the cache page.

Edited September 22, 2022 by simon_cornelus

[Frau Potter]

We are aware of this issue. The engineers are actively working to fix this bug. It will take several days before it is corrected. In the meantime, the values may be temporarily incorrect or missing. 

[+capoaira]

Looks like the bug is fixed. Thank you

[+yukionna]

I’m not sure the bug is fixed or perhaps there is another issue with the percent favorite calculation.   I saw a cache that has a total of 13 logs: 12 found it logs and 1 cache publish log.   The cache has 12 favorites all from from premium members.  I would have expected to see a favorite percentage of 100% but the percent is 92%.  That makes me draw the conclusion that the calculation includes the publish log because 12 favorites divided by 13 total logs = 92%.  

[+yukionna]

Never mind, all is well.  Unless someone just modified the code, it seems there is a few hours delay, after the FP is added, in the recalculation of the percentage.  It is curious though as when the FP was added earlier today, the 100% dropped immediately to 92%.  Now, five hours later, it just recalculated to 100%.  Perhaps the % is calculated twice: first when the FP is awarded using one set of code; second later on, using different code, to recalculate.  🤷‍♀️
 😊

Edited December 5, 2022 by yukionna

[+barefootjeff]

On 12/23/2022 at 11:57 AM, BendSinister said:

Something still seems to be amiss, in at least some cases. It's almost like the percentage updates with a subsequent log, such that the ratio is constantly out of date, using numbers that applied up until that latest log. Or something. The situation seems to persist until the next change in the numbers.

 

I think you've hit the nail on the head with this. I've been watching the FP percentage on a newly published multi and it always seems to be ignoring the most recent log.

[+MartyBartfast]

It's been discussed elsewhere that the way the website calculates the % score for favourites is wrong, but I just saw something that is so wrong it's frankly bizarre.

Consider this cache which I logged a find on 2 days ago: 11 finds, of which 10 are PM, and 3 favourites, so that should be  either 27% or 30% depending on which count you're using, but the website shows 40% (see  screenshot)!

Then when I went to add an FP to my log from 2 days ago  it records my FP, so now 4 out of 11 or 10 finds , which should be 36% or 40%  but it now calculates it to be 30% (see screenshot).

Whatever method is being used to work out the percentage how on earth can adding an FP (without adding a log entry) lower the % score

[+Bl4ckH4wkGER]

I merged a duplicate thread.

[+Viajero Perdido]

It's still wonky.  Perhaps this quasi-random number should be removed until it can be made correct.  Here, I kept clicking Remove/Add, same backwards result every time.

 

 

I've also found I can permanently increase a cache's mock-percentage by adding then removing a favorite point ... but only once per cache.  (If everybody does this, can we get over 100%?)

 

Edited March 6, 2023 by Viajero Perdido

[+barefootjeff]

2 hours ago, Viajero Perdido said:

I've also found I can permanently increase a cache's mock-percentage by adding then removing a favorite point ... but only once per cache.  (If everybody does this, can we get over 100%?)

 

That's just recently happened on one of my caches. Prior to the most recent find, it had 4 FPs from 5 PM finds and was incorrectly showing 75% FPs, now after the most recent finder logged it and gave it an FP (so it's now 5 from 6) it's showing this:

 

 

What's even more curious is she gave the FP with her log, as it shows in the log email, so I don't know how it got double-counted, unless perhaps she then went to the website, removed it and re-added it.

[+Viajero Perdido]

Darn ... I couldn't push you past 100% with a temporary found log and some favorite diddling.  Instead that just brought it down to 86% ... sorry!

 

But 5/6 is 0.83, rounded.

 

6/7 happens to be 0.86, rounded.

 

Math is hard.

[+barefootjeff]

12 minutes ago, Viajero Perdido said:

Darn ... I couldn't push you past 100% with a temporary found log and some favorite diddling.  Instead that just brought it down to 86% ... sorry!

 

Yep, so I now have:

• GC9M6X5 with 5 FPs from 6 PM finds showing 100% FPs
• GC9ZM7G with 6 FPs from 6 PM finds showing 86% FPs.

This has long since stopped being funny, HQ...

[+barefootjeff]

This one must take the cake with 1 FP from 1 find but <1% favourites/PM logs:

 

 

Maybe it's only counting FPs awarded from the app?

[+HouseOfDragons]

This is happening on one of my caches - 10 FP from 10 finders and a percentage of 90%.
 

i see they only ever said they were "working on it" last September and never confirmed it had been fixed though.

[+barefootjeff]

A bit more observation on my latest cache (GCA5HGT) which now has 4 FPs from 4 finds but is showing 75% FPs:

 

It appears the percentage FP calculation is only done when a log is posted and ignores any FPs that are added from the cache page afterwards, i.e.

 

 

The silence on this issue from HQ since it was first reported 6 months ago is disturbing. I guess since this only really affects caches with small find counts, it's been deemed inconsequential.

[+Viajero Perdido]

The types of people who are attracted to this game ... seem to be the types who are also into statistics ... and maybe it really annoys them if those stats aren't accurate.

 

Maybe this deserves more attention.

 

I don't personally care that much, but do have a(-n annoying?) compulsion to report bugs when I see them.  It comes from my background in software development.

[+barefootjeff]

2 hours ago, Viajero Perdido said:

The types of people who are attracted to this game ... seem to be the types who are also into statistics ... and maybe it really annoys them if those stats aren't accurate.

 

For unpopular caches like my more recent ones that are condemned to single-digit find counts, the percentage FPs is about the only statistic worth looking at. And as a retired engineer, it bothers some essential part of my core to see incorrect information displayed, more so when the response from those responsible is, well, crickets.

[+OGuyDave]

Same deal here for a cache that was just published on April 1:

 

Pretty sure that the last logger added his favorite point a day after submitting his log.

 

Would be nice to see HQ get their heads together and fix this problem. Or maybe it's HQ's attempt at humor based on the day the cache was published! Nah!

 

 

[+HouseOfDragons]

Is this ever going to be fixed (or even a comment that it's being looked at would be nice!) 

[+baer2006]

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

[Johannis10]

So far not all bugs have been fixed as you can easily see here right now without calculation:

https://coord.info/GC9F8ZF

5 findes and 5 FP is not 80%

Edited April 8, 2023 by Johannis10

[+barefootjeff]

2 hours ago, baer2006 said:

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

 

Just displaying what it used to display back before they changed things last September would be a good start. Right now it's just wrong whichever way you define it.

[+Viajero Perdido]

Has anybody figured out how to game this to simultaneously +1 the favorite count, and increase the fave percentage?  (...as would happen in reality.)

 

I'm trying to figure out how to deliver a proper compliment, not a half-cheeked one.  [:D]  I say nice things with words, of course, but nobody reads those.

[+HouseOfDragons]

On 4/8/2023 at 7:32 PM, baer2006 said:

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

A) The simple approach would be #FP/(# of finders, who are currently PM). But this can easily lead to totally misleading percentages, because when a PM, who has given an FP, becomes BM (e.g. because the quit the game, and let the premium membership expire), the FP remains. Example: A cache with 10 finds, 6 FP, but only 2 finders are PM (because 4 of the those with an FP are now BM). So what's the percentage now? #FP/#PM-finders would give 300%, which doesn't make sense.

 

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

 

C) One could even define it like this: #FP/(#FP + # of finders who are currently PM and did not give an FP). Sounds complicated, but boils down to counting in the denominator all finders, where we know they could have given an FP: Those who actually gave one plus those who are currently PM and therefore could give one.

 

Both B and C should be easily query-able from the database, using only persistent information (i.e. who has found the cache, who is currently PM, and who has given an FP).

Why would you want it to be anything other than "what  percentage of people eligible to give a FP gave this cache  a FP"?

 

I'd settle for correct. 10 out of 10 isn't 90%

[+Etherlord Clan]

Hi Team,
I'll throw my hat into the ring as well

I have a new gadget cache that has 11 Found It logs and collected 11 FPs, yet is only at 91% thanks to the "Published" log making a total of 12 logged visits and throwing off the % calculation.

 

Thanks,
Thomas

 

Edited April 13, 2023 by Etherlord Clan

[+2Abendsegler]

Before our log the cache had 26 favorite points and 68%. With the log via the new log form we have set a favorite point. The listing also included the 27 favorite points. Unfortunately, the percentage was reduced to 67%. We then removed the favorite point via the listing and added it again in the hope that it would then be displayed correctly. When it was removed, the old values of 26 points and 68% were restored. On adding it got even worse with 27 points and 65%. We can remove and add again and again with the same result. I might as well shoot a little clip of it.

Really very unfortunate that you haven't been able to correct the obvious bug for months. It's particularly unfortunate because it used to work. It also seems questionable whether all past data can be reproduced again.

[+barefootjeff]

The silence on this issue is becoming deafening, with it now eight months since the OP in this thread. The latest example is GCA703Y which has had two finds, one by a basic member, and received an FP from the other:

 

 

If it's no longer possible to correctly show the percentage FPs, why show it at all?

[+worrellsquirrel]

This issue is still being investigated by our engineering team. We apologize for any inconvenience but thank you for your patience in the meantime.

[+Viajero Perdido]

On 5/18/2023 at 12:22 PM, worrellsquirrel said:

This issue is still being investigated by our engineering team.

 

What was the result?

[+barefootjeff]

Happy birthday to this bug.

 

[+Deepdiggingmole]

Today I noted on one of my caches that the %age figure as given in the FP box did not tally with the number of FPs points given over the number of finds 
As per the image both are 5 (newish cache) however the %age figure says 80%
One of these finds was today though when you look in the 'View who favourited' link it does show all 5 who have found it are on that list including today's finder - so would have thought that would be 100% 

So is there a delay in that %age figure updating or is there an issue with this 
 

(Note I had started a post on this topic as I hadn't found this thread - have added it here to show this issue is still unresolved)

[+barefootjeff]

39 minutes ago, Deepdiggingmole said:

So is there a delay in that %age figure updating or is there an issue with this 

 

No delay, it's just broken. This cache of mine, with one find and one FP, was found nearly four weeks ago but it's still showing <1% FPs.

 

 

I have a picture with two candles on a cake ready to post next September.

[+Deepdiggingmole]

...and yet it does show it correctly too - this one, (see attached) 15 finds 15 FP and shows as 100% and the latest find was earlier this year (relevant to when this thread was orignally posted)

My 2 examples are the easier to show whether the %age figure is correct, becasue all finders gave a FP - I am aware with PM and non-PM logs and also PMO caches these figures can be a little skewy - however both my examples though being non PMO caches - with all finds, all have given FPs 

I will monitor my earlier example and see if it does eventually change as that does suggest either there is a time lag issue or it gets repaired and it keeps breaking

 

Edited November 8, 2023 by Deepdiggingmole

[+Deepdiggingmole]

On 4/8/2023 at 7:32 PM, baer2006 said:

A better approach would be (#FP given by current PMs)/(# of finders, who are currently PM). With this definition, the above example would give 100% - the two remaining PM finders both gave an FP. How many ex-PMs gave an FP in the past would be irrelevant.

Just reading through the past posts on this as I have only just joined in) the above suggestion though using my example where there have been 15 finds and 15 FPs given out - if for example 5 of these let their PM lapse so now only 10 are PM then the %age figure would still be 100 as you indicate however that isnt telling me 100% of ALL finders gave that cache an FP (which is what I would expect out of that stat ), it is essentially saying 67% of all finders have given an FP as we are  going to ignore some of them 

 

Edited November 8, 2023 by Deepdiggingmole

[+baer2006]

13 minutes ago, Deepdiggingmole said:

Just reading through the past posts on this as I have only just joined in) the above suggestion wouldnt work using my example where there have been 15 finds and 15 FPs given out - however if 5 of these let their PM lapse so now only 10 are PM then the %age figure would be 100 as you indicate however that isnt telling me 100% of ALL finders gave that cache an FP (which is what I would expect out of that stat ), it is essentially saying 67% of all finders have given an FP but we are not going to count them all 

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

[+Deepdiggingmole]

5 minutes ago, baer2006 said:

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

No - but I am well aware that if you factor in non PM then it wouldn't and I am aware of that when I look at that %age figure it only counts PM finds (not discussing PMO as has already been stated that only PMO caches would give a more accurate figure). So I look at a non PMO cache and I know that that %age figure will reflect the stats based on PM finders only - and that doesnt bother me because I know only PM can give an FP - so I look at it and if it says 26% , I know that means 26% of PM finders have awarded an FP - I dont then go and look at the number of total finds and say it is wrong 
In my example and with the suggestion that you gave where a few had PM lapsed - yes, it would produce a figure that may be "stable" and reproducible - but, inaccurate because it is discounting FPs that have been given - why would you want to discount FPs in a figure that has the sole function of measuring FPs

[+Deepdiggingmole]

3 hours ago, baer2006 said:

Sorry, but I don't see your problem. Of course, the FP % stat doesn't "count them all", because non-PM simply cannot give an FP. So if a cache has 15 finds, and 10 of these are currently(!) PM, and all those 10 current PMs have given an FP, then it should say "100%". Such a calculation scheme ignores FPs by former PMs, true. But in my view, only taking the current FP per PM percentage into account would be the most "stable" and reproducible method.

and to answer the statement 

Before attempting to "fix" anything here, one must first establish a rigorous definition of the metric "percentage of FP". And I don't think that's super easy.

Basically, it should be "#FP / #(Logs from PMs)", because that's what it says on the listing page: xx% Favorites/Premium Logs

 

I have just checked another of my caches to see how the PM non PM issues stands up and it would seem the %age figure only counts the PM 

26 finds of which 25 PM, 1 non PM and 16 FP - if ALL finds were counted then the %age would be 61 - if only PM finds were counted then the %age would be 64 
The stat shows 64% - which does indicate it is ignoring non PM - so in essence it is correctly counting all the relevant find logs for that stat - those by PM 
That is a fairly new cache (1 year old) so I doubt lapsed PM accounts are an issue - so yes, it is "#FP / #(Logs from PMs)"
and yes, I agree that lapsed PM accounts would skew these stats - I have just checked one of my older caches -  1159 finds, 917 by premium members, 246 by non-PM, 359 FPs this should work out as 31% if all find logs are counted or 39% if only PM counted - the FP box shows 38% so suggests again this does only take into consideration PM finds (39% is my calculation and it is very likely that 1% is the difference of lapsed PM which is between 10-20 cachers - though to identify those accounts that had been premium and are now non PM is doable but would take ages ) but again I would say it is "#FP / #(Logs from PMs)"

 

However what the glitch is - who knows 

Edited November 8, 2023 by Deepdiggingmole

[+Deepdiggingmole]

31 minutes ago, Deepdiggingmole said:

31% if all find logs are counted or 39% if only PM counted - the FP box shows 38% so suggests again this does only take into consideration PM finds (39% is my calculation and it is very likely that 1% is the difference of lapsed PM

Having looked at this closer - I have now established there were 34 PMs who gave FPs who are now shown as basic (Non PM accounts) (its pouring with rain so I'm enjoying sitting at the PC today  )
So where the logs show 917 by premium members, 246 by non-PM this would be amended to 951 PM, 212 non PM with the account change taken into consideration 

this means the %figure would be 37.7% - I then wondered about those PM accounts that similarly lapsed and are now basic but didn't give FPs as that would also affect this number - but I dont have the time to disseminate those stats (even though it is raining !!!! )

So does this mean their calculations do take all this into consideration  - despite there being a glitch 

 

 

I hope this rain stops soon - I can't sit here all day researching this dribble 

 

[+MrDosinger]

It's really weird behavior. A small additional piece of evidence, to keep the flame alive and maybe encourage HQ to keep working on this. Unlike some of the other posters, I've observed mostly correct percentages on our non-PMO mystery caches GC9PTR9 and GCA421M in recent months. We get logs every few days, most people kindly award a favorite point, and we've become a bit addicted to following this game day by day which makes it easy to collect many observations on how this works. We've seen plenty of small delays in updating the percentage on the website, but so far, they're correct. We're at 95% for one and at 99% (at least until today) for the other.

 

Now, the weird bit: Today's change for GCA421M did not coincide with a new log, and it suddenly increased the cache's FP % to 100% with 148 favorites out of 151 logs. Up until now, we've had two basic members and one premium member who did not award an FP, so the formula should be 148/149, which is 99.3% -- and indeed: yesterday, were at 99%, not 100%. Now I ran down the logs again and confirmed those numbers: two basic members logged, and one PM did who did not award an FP. The other 148 PMs did.

 

Since we've established that delays in updating the FP% are common, what other data could be delayed/out of date and still feed into this calculation? May someone's premium membership have lapsed without it being visible on their log yet? I did not visit very logger's profile page to double-check, but it's not inconceivable that there would be some caching of such data to avoid too many database queries just to display logs on a cache listing.

 

I hope HQ keeps working on this, and maybe cleaning up whatever complicated combination of systems seem to feed into each other in the background to produce these bugs.

Edited December 16, 2023 by MrDosinger

[+barefootjeff]

6 minutes ago, MrDosinger said:

It's really weird behavior. But maybe they've fixed part of the problem by now.

 

Still pretty badly broken from where I'm sitting. My most recent cache GCAEX05, published in early October, has one find and one FP, both dating from about a week after publication but the original log was a field log with more to come and the FP was added a day or two later when the finder fleshed out his log. This one is still showing <1% FPs:

 

 

On my other hides, some are correct, some not, and of the latter, some show the percentage higher than it should be and some show it lower. There doesn't seem to be any rhyme or reason to it, making me suspect it's a software race condition when a log or FP is added (or removed, I suppose).

 

 

[+MartyBartfast]

I just went and looked at 10 caches I recently put out. All 10 have only 3 finds from the same 3 PMs, no DNFs. 8 of them show 100%, 2 show 67% . One of the ones with 67% does have a note from a PM but the other doesn't.

Frankly it's quite bizarre how unpredictable this is, and it shouldn't be difficult to get right .

[+MrDosinger]

On 12/16/2023 at 11:30 AM, MrDosinger said:

Now, the weird bit: Today's change for GCA421M did not coincide with a new log, and it suddenly increased the cache's FP % to 100% with 148 favorites out of 151 logs. Up until now, we've had two basic members and one premium member who did not award an FP, so the formula should be 148/149, which is 99.3% -- and indeed: yesterday, were at 99%, not 100%. Now I ran down the logs again and confirmed those numbers: two basic members logged, and one PM did who did not award an FP. The other 148 PMs did.

And as expected, as the next log came in, the wrong FP calculation changed again -- this time, it fixed itself. Back to 99%.

 

I agree, this should be fixable. Would be great to get an update from HQ.

[+LydiaSimmons]

If there is a database challenge associated with counting the number of premium logs efficiently, I would (controversially?) suggest just using the number of total found it logs in the denominator, which is already computed and shown in the logs section.  I suspect this would be simpler to implement and while the denominator may not reflect the true number of those who could possibly give it a favorite point, it would even out over time in my opinion across caches.  COs could make their cache premium-member only if they were concerned about this, though of course the cache could still be logged by basic members.

Edited December 28, 2023 by LydiaSimmons
clarity

[+barefootjeff]

3 hours ago, LydiaSimmons said:

If there is a database challenge associated with counting the number of premium logs efficiently, I would (controversially?) suggest just using the number of total found it logs in the denominator, which is already computed and shown in the logs section.  I suspect this would be simpler to implement and while the denominator may not reflect the true number of those who could possibly give it a favorite point, it would even out over time in my opinion across caches.  COs could make their cache premium-member only if they were concerned about this, though of course the cache could still be logged by basic members.

 

The problem isn't related to counting PM logs as the error occurs on caches where the only logs are from PMs (like my one I quoted recently that has one PM find with one FP but shows <1% FPs). In any case, this used to work properly until they changed something around September last year.

[+LydiaSimmons]

4 hours ago, barefootjeff said:

 

The problem isn't related to counting PM logs as the error occurs on caches where the only logs are from PMs (like my one I quoted recently that has one PM find with one FP but shows <1% FPs). In any case, this used to work properly until they changed something around September last year.

I don't think that means the problem is unrelated to counting premium member logs.  The numerator seems to be right, it's the percentage that seems to be wrong, and my inference is that the denominator is the problem.  

Edited December 29, 2023 by LydiaSimmons

[+barefootjeff]

On 12/29/2023 at 7:43 AM, LydiaSimmons said:

I don't think that means the problem is unrelated to counting premium member logs.  The numerator seems to be right, it's the percentage that seems to be wrong, and my inference is that the denominator is the problem.  

 

Examples from my own hides where the numerator is wrong:

• GCAHPD9: 1 FP / 1 find (PM) = 0% FPs (should be 100%)
• GCAEX05: 1 FP / 1 find (PM) = 0% FPs (should be 100%)
• GCA2XYJ: 3 FPs / 8 finds (all PM) = 29% FPs (should be 38%)
• GCA25XJ: 10 FPs / 13 finds (all PM) = 75% FPs (should be 77%)
• GC9JDPF: 10 FPs / 14 finds (all PM) = 64% FPs (should be 71%)

The problem seems to be it not updating correctly on the most recent find, either ignoring the FP but counting the find or not counting either.

[+LydiaSimmons]

Numerator is displayed accurately on the top of the cache page.  Total number of finds is displayed accurately on the bottom of the cache page. I'm just saying, there's enough information on the page to calculate a FP percentage.  Premium logs is not well-defined anyways as memberships get renewed, and lapse, etc.

[+barefootjeff]

Yet another example (if any more are needed) after a couple of new logs today:

• GCAHPD9: 3 FPs / 4 finds (all PM) = 67% FPs.

Again it doesn't seem to be counting either the find or the FP of the most recent log.