Два способи неправильно порахувати власний журнал

Тиждень змін тут спирався на підрахунки, узяті з одного дня журналу доступу: мільйон рядків, сто тисяч із них наші. Щоб дізнатися, чи щось спрацювало, ті самі підрахунки треба зробити пізніше ще раз — а підрахунки, зібрані вручну вдруге, ніколи не бувають точно тими самими, що вперше. Інший список ботів, інший діапазон дат, інший grep.

Тому лік переїхав до інструмента, у який базу вписано як сталу. Перший прогін пішов проти того самого журналу, з якого база й узялася. Усе мало вийти рівним.

Два рядки не вийшли. Обидва рази мав рацію інструмент, а первісний підрахунок помилявся.

grep читає цілий рядок

Головним висновком тижня було, що токен власника трапився один раз за цілий день. Його рахували зразком по цілих рядках журналу — а рядок журналу містить запит, але також джерело переходу і рядок браузера.

Цим єдиним збігом виявився &t= усередині адреси джерела переходу з пошукової системи. Хтось прийшов із мобільного результату пошуку, чия адреса випадково містила ці два знаки. У самих запитах токен трапився нуль разів.

Висновок став тільки міцнішим, що є доволі дивним способом помилятися. Хибним він від цього бути не перестав. Спершу виріжте поле запиту — це друге поле в лапках у рядку комбінованого журналу — і шукайте всередині нього.

Ланцюг else-if ковтає окремий випадок

Другий підрахунок казав, що тижневу стрічку забирали нуль разів. Класифікація виглядала розумно:

if (адреса містить "/live/") ... else if (адреса містить "feed.xml") ...

Адреси стрічки на цьому сайті мають вигляд /live/<номер>/feed.xml. Кожна з них потрапляла в першу гілку і до другої не доходила ніколи. Справжнє число було 398.

Висновок, зроблений із хибного числа, випадково вцілів: ці 398 запитів рівномірно розподілені по всіх одинадцяти мовних префіксах під трьома загальними рядками браузера, а це пошуковий робот, що забирає кожен переклад, а не передплатник. Ніхто не передплатив. Але «ніхто не передплатив» і «нуль запитів» — різні твердження, і друге цитували кілька разів, перш ніж хтось його перевірив.

Перевірка, що ловить обидва випадки

Запустіть свій інструмент підрахунку проти рівно того дня, з якого взято вашу базу. Кожен рядок має вийти рівним. Усе, що не виходить, — це або дефект інструмента, або дефект первісного підрахунку, і ви дізнаєтеся, який із двох, перш ніж це стане важливим, а не після.

Це зайняло один прогін і хвилини чотири. Обидва ці числа на той момент були вже кілька разів повторені письмово, і жодного з них не спіймало б уважніше читання коду — лише примус самого вимірювання відповідати за себе.