Update: 09/07/2025

26-28 June – Late PBS

Info about live statistics is at the bottom, below the tables.

Technical note in Polish:

Po naszemu nieprzypadkowo (można przewinąć jkbc, ryli tylko dla bardzo zainterere), bo zasadniczo chciałem sprawdzić, czy da radę z festiwalem, który się odbył ponad tydzień temu (czyli wtedy, kiedy się o tym konkretnym dowiedziałem z inszych tabelek). A przypominam, że na UT większość stron pokazuje tylko ostatnie 270-300 czekinów. I okazuje się, że w dobrych układach – i owszem, zasadniczo da radę, przy czym to cokolwiek pracochłonne (kilkukrotne naprzemienne puszczanie sciągania PBS z czesaniem zaległych czkn userów i nastepnie czesanie czekinów piw znalezionych na wcześniejszym etapie), w efekcie czego mamy takie przyrosty po każdym kolejnym kroku (całość trwała ponad 12h):

Kolejna iteracja (Piwa 3) już nie dała nowych czkn.

No i nieźle, bo na UT jest Venue do porównania, na którym widać Monthly: 15057. Czyli jednak zauważalnie więcej (udało się osiągnąć ~87% widocznego na UT Monthly). Oto skąd różnica:

  • PBS zbiera dane od mniej więcej startu festiwalu, nie wcześniejsze (teoretycznie – tutaj jak widać w tabelkach tam dalej, załapało się też trochę starszych, ale to wina tego uzupełniania z piw, daty z d niekiedy, w sumie nwm kiedy), zaś „monthly” i owszem, pokazuje wszystko, a więc i ewentualne (dużo) wcześniejsze
  • PBS nie uwzględnia czekinów z ukrytych kont. Monthly i owszem. To duża różnica. Zasadniczo – największa. Zależnie od kraju, festiwalu, pogody w Burkina Faso – ale od kilku do nawet kilkunastu % czkn tak „znika”
  • PBS zbiera dane tylko dla venue oznaczonego w czekinie jako „location”. Monthly sumuje również „purchased location” – to może być ładne kilka procent, zwłaszcza po jakimś czasie od festiwalu
  • Monthly uwzględnia również wszystkie skasowane czekinki w danym venue, PBS tylko niektóre (tylko te, które zdąży zauważyć przed skasowaniem)
  • i dopiero po uwzględnieniu wszystkich powyższych różnic (których nie wiadomo iloma czekinami rozjazdu owocują) pozostała rozbieżność to ewentualne „stracone” przez PBS w związku z upływem czasu bądź jakimiś błędami. Możliwe, że takich jest okrągłe zero a przynajmniej symbolicznie mało. A trzeba przyznać, że ten festiwal miał ryli duże szanse na nadrobienie półtoratygodniowego opóźnienia bez strat (dedykowane venue, nie jakieś kolosalne liczby czekinów, nieco specyficznych piw)

Koniec technikaliów.

Basic info:

  • If someone is watching from the phone, it’s best to hold your phone horizontally (or scroll the tables horizontally)
  • All tables are pageable, sortable, and filterable (’search’).
  • All dates and times in the tables are shown in DD/MM/YYYY format, in local festival time (unless stated otherwise)
  • With a large number of checkins / people / beers, there may be some delays in updating, discrepancies between the tables (especially at the beginning of the festival), which will level out after some time. Plus, there will probably be unloaded pictures – that will take time, because pics have a lower priority than check-ins.
  • In this context, 'live’ means 'every few minutes’ – but see above – the beginning of major festivals can be challenging
  • UT accounts hidden by users are not included in the statistics
  • Only checkins that have monitored venue marked as „Location” are taken into account („Purchased Location” is not enough). Which venues are monitored can be seen in the first table
  • The tables on the page do not refresh automatically – you will have to reload the page in your browser if necessary. There’s nothing worse than an automatic reload of a table you’re analyzing after sorting and filtering…
  • Edits on UT made with a delay are taken into account live only for a few / tens of seconds, but not selecting a venue and adding it later, or changing a beer or rating will be included with a delay (limited to last 300 checkins per user)
  • If you use a third party application (e.g. jonpacker.com for MBCC), you may be skipped (workaround: do the first check-in normally, with UT and sync data between the third-party app and UT every 200-250 check-ins). UPD: Since UT changed their API policy, this potential problem seems to be fading away, as there’s a good chance all similar 3rd party apps are disappearing too.
  • If you don’t show up in the stats, make sure you don’t have a hidden account or „shadow-ban” – especially check if your checkins are visible on the venue’s page.
  • Top3 columns in the tables do not recognize ties – always only 3 positions, if there are ties in values, the order is determined chronologically. Also, for top3 ratings, a minimum of 3 ratings is required to be included.
  • The „Fest. Hate / Hype” column is the difference between the UT arithmetic average (at the moment of the first checkin at the festival, without subsequent updates) and the arithmetic average of ratings at the festival. If the beer did not have an UT average on the start of festival, the Hate / Hype is 0.
  • If you don’t know what Bayesian average is, I invite you >>here<< (unfortunately in Polish, but with pics & links to english language pages)
  • There are (as per Brewer Stage) minimum number of checkins for beers and breweries to be included in the tables. You can see the required numbers in the first table with parameters or on that chart
  • The Bayes average for breweries is based on all ratings the brewery has received, rather than the average of its beers. This new method doesn’t match the original Brewers Stage approach, but after tons of simulations, checks, and testing, it proved to be more reliable and just more intuitive.
  • Backlogs / late check-ins will be collected about a day after the end of the festival
  • The tables will be trimmed if their data exceeds 2 MB (applies only to exceptional cases / largest festivals and only to tables of users and beers. 2 MB = about 4K users or 2K Beers).
  • Remember – the fact that a beer has a low rating does not mean that it is bad, but only that some other people did not like it. You may have different taste 🙂
  • If anything’s unclear, you have questions, spot any mistakes, or – for example – want another festival included -> feel free to reach out (FB Messenger: Profile Picture Rami Ramidus).
  • I hope that nothing will fail (it works on an old laptop at home), but anyway: I do not take responsibility for anything (in particular: for the correctness of data), and I wish you nice statistics :>