Dlaczego wtyczka WooCommerce lub aplikacja Shopify ma instalacje, ale nie ma płacących użytkowników, i procedura go-to-market, która to naprawia

Własne wtyczki WooCommerce wydaję pod marką plogins i widzę ten sam wzorzec w moich statystykach oraz w narzędziach, które pokazują mi agencje: licznik instalacji rośnie, płatny plan stoi w miejscu. Listing sprawia, że ktoś klika “Zainstaluj”. Potem nikt nie wie, czy użytkownik dokończył konfigurację, zobaczył efekt, czy usunął wtyczkę jeszcze tego samego popołudnia.

Ten poradnik to procedura, którą stosuję, żeby ustalić, w którym miejscu ludzie odpadają, i to naprawić. Obejmuje wtyczki z WordPress.org i aplikacje z Shopify App Store obok siebie, bo problemy są podobne, choć sklepy z aplikacjami działają inaczej. Każdy limit poniżej pochodzi z dokumentacji danej platformy i ma link obok faktu. Tam, gdzie platforma niczego nie dokumentuje, piszę o tym wprost.

Jeśli prowadzisz wtyczkę albo aplikację jako produkt, albo jesteś agencją z własnymi narzędziami, to jest praca, którą wykonuje go-to-market engineer: listingi, pomiar onboardingu i treści, które idą za kolejnymi wydaniami.

#Dlaczego moja wtyczka WooCommerce ma instalacje, ale nie ma płacących użytkowników

Instalacje mierzą listing. Płacący użytkownicy mierzą wszystko, co dzieje się po nim. Gdy te dwie liczby się rozjeżdżają, luka siedzi w jednym z czterech miejsc:

1. Listing przyciąga niewłaściwego czytelnika. Tagi, frazy wyszukiwania albo krótki opis pasują do zapytania, którego intencji twój produkt nie obsługuje. Takie instalacje odpadają, bo produkt odpowiada na inne pytanie.
2. Konfiguracja jest za długa albo niejasna. Użytkownik aktywuje wtyczkę, trafia na stronę ustawień z dwudziestoma polami i wychodzi. W Shopify to samo dzieje się na osadzonym ekranie w panelu administracyjnym.
3. Pierwszy efekt przychodzi późno. Wtyczka do wysyłki, która sprawdza się dopiero przy następnym zamówieniu, zostawia długą przerwę między instalacją a wartością. Wielu użytkowników odinstalowuje ją w tej przerwie.
4. Przejście na płatny plan nie ma wyzwalacza. Darmowa wersja rozwiązuje problem wystarczająco dobrze, a nic w produkcie nie podpowiada, kiedy pomogłaby wersja płatna.

Po samej liczbie instalacji nie odróżnisz tych przypadków. Potrzebujesz kilku liczb mierzonych tak samo przed każdą zmianą i po niej. To pierwszy krok procedury, a większość autorów wtyczek go pomija.

#Co zmierzyć, zanim zmienię listing wtyczki

Zanim ruszysz choć jedno pole, zapisz stan obecny. Bez kolumny “przed” każda późniejsza zmiana jest tylko opinią. Dla każdego produktu prowadzę jedną tabelę i uzupełniam ją w stałych odstępach, na przykład z czterech tygodni przed zmianą listingu i czterech tygodni po niej.

Oto szablon. Kolumny Przed i Po są puste celowo: wpisz własne dane.

Trzy zasady pilnują uczciwości tej tabeli:

• Ustal stałą długość okresu. Cztery tygodnie przeciw czterem tygodniom. Krótsze okno “po” przecenia efekt zmiany.
• Zmieniaj jedną rzecz na okres. Jeśli w tym samym tygodniu przepiszesz listing i onboarding, nie dowiesz się, co ruszyło liczby.
• Zapisz definicję, zanim odczytasz liczbę. “Konfiguracja ukończona” oznacza konkretny zapisany stan. Najpierw zdecyduj, jaki to stan, potem go licz.

Podział na płacących i darmowych w wierszach o użyciu funkcji pochodzi od Mata De Sousy, założyciela WideBundle. W poście na X z 2 listopada 2026 zalecił on osobne śledzenie użycia funkcji w obu grupach, obok odinstalowań tego samego dnia, ukończenia onboardingu i retencji. Jego zdaniem funkcje, z których faktycznie korzystają płacący, mówią, co sprzedaje plan płatny. Zgadzam się z tym podziałem i dodam jedno: jeśli funkcja jest intensywnie używana przez użytkowników darmowych, a rzadko przez płacących, to kandydat na wyzwalacz upgrade’u.

#Jak wypełnić listing wtyczki na WordPress.org pole po polu

Listing na WordPress.org powstaje z pliku readme.txt. Poniższe reguły pochodzą z dokumentacji readme. W prawej kolumnie jest to, co sprawdzam we własnych plikach readme przed każdym wydaniem.

Krótki opis niesie najwięcej, bo pojawia się tam, gdzie użytkownicy porównują wtyczki. Piszę go jednym zdaniem: co wtyczka robi dla sklepu WooCommerce, językiem właściciela sklepu. W plogins-customs są to cła, dokumenty celne i dokumenty przewoźnika, czyli słowa, których używa sprzedawca wysyłający towar poza UE, a nie nazwa rozporządzenia.

Jest też sprawa języka. Przeglądarkę wtyczek w polskim panelu WordPressa czyta sprzedawca, który szuka rozwiązania po polsku, więc krótki opis i FAQ w readme mają nazywać problem tak, jak pisze go polski właściciel sklepu: faktura, przesyłka, cło, deklaracja. Nazwy własne funkcji zostawiam na koniec opisu.

Długi opis i sekcja FAQ w readme służą do odpowiadania na pytania, które blokują konfigurację. Każde pytanie z forum wsparcia przenoszę do FAQ w readme, w brzmieniu, w jakim zadał je użytkownik. Z wątków wsparcia robię w ten sposób treść listingu i skracam drogę następnej osoby do działającej konfiguracji.

O budowie wtyczek dla sklepów WooCommerce piszę szerzej na stronie programista WooCommerce.

#Jak wypełnić listing aplikacji w Shopify App Store pole po polu

Shopify dokumentuje znacznie więcej szczegółów listingu niż WordPress.org. Wszystkie liczby z tej tabeli pochodzą z dobrych praktyk Shopify App Store.

Dwie dodatkowe pozycje z tej samej strony zmieniają sposób, w jaki planuję listing:

• Tłumaczenia. Shopify podaje, że przetłumaczone listingi “konwertują do 4 razy lepiej na rynkach nieanglojęzycznych” (tłumaczenie własne), a angielskie listingi główne są tłumaczone automatycznie na 8 języków: brazylijski portugalski, duński, holenderski, francuski, niemiecki, chiński uproszczony, hiszpański i szwedzki. Na tej liście nie ma polskiego. Jeśli chcesz sprzedawać polskim sklepom, polski listing musisz przygotować ręcznie, bo automat go nie zrobi. Angielski listing główny piszę krótkimi, dosłownymi zdaniami, żeby tłumaczenie maszynowe miało mniej okazji do błędu, a wersję niemiecką i hiszpańską sprawdzam ręcznie.
• Wydajność witryny sklepu. Shopify wymaga, by aplikacje nie obniżały wyniku wydajności Lighthouse o więcej niż 10 punktów. Wynik jest ważony: strona główna 17%, strona produktu 40%, kolekcja 43%. Jeśli aplikacja cokolwiek wstrzykuje do witryny, przed zgłoszeniem mierzę te trzy typy stron z aplikacją i bez niej.

Zrzuty ekranu i wideo to miejsce, w którym problem onboardingu z pierwszej sekcji staje się widoczny. Jeśli nie umiem zrobić sekwencji od trzech do sześciu zrzutów, która prowadzi od instalacji do pierwszego efektu, konfiguracja jest za długa, a poprawianie zrzutów nie naprawi produktu.

Jeśli budujesz samą aplikację, stronę o implementacji znajdziesz pod hasłem programista Shopify.

#Co zmienia odznaka Built for Shopify

Built for Shopify to jedyne miejsce, w którym Shopify mówi, że coś wpływa na wyszukiwanie. Według tej strony status daje:

• odznakę na karcie aplikacji i wyróżnienie w listingu,
• filtr w wyszukiwarce i podbicie pozycji w wyszukiwarce App Store,
• priorytetowy przegląd i kierowanie reklam w planie reklamowym,
• kwalifikację do pierwszej kolekcji na stronie głównej i w kategoriach oraz do “Picked for you”, które Shopify opisuje jako spersonalizowane i niegwarantowane.

Kryteria obejmują bezpieczeństwo i niezawodność; wydajność w panelu administracyjnym oraz w witrynie lub kasie, jeśli aplikacja ich dotyka; łatwość obsługi; udowodnioną użyteczność mierzoną instalacjami; liczbę i ocenę recenzji w ruchomym oknie czasowym; oraz kompletny listing. Aplikacja musi być osadzona w panelu administracyjnym Shopify.

Proces ma konsekwencje. Trzykrotne niespełnienie tego samego kryterium z rzędu zawiesza wniosek na trzy miesiące. Status jest przeglądany co roku, a aplikacja, która spadnie poniżej kryterium, ma 60 dni na poprawę.

W planowaniu traktuję kryteria jak listę kontrolną, która prawie w całości pokrywa się z pracą nad onboardingiem opisaną niżej. “Łatwość obsługi” i “udowodnioną użyteczność” trudno pokazać bez zdarzeń konfiguracji i pierwszego efektu, więc najpierw instrumentuję, a dopiero potem składam wniosek. Zgłoszenie za wcześnie i wielokrotne oblanie tego samego kryterium kosztuje trzy miesiące.

#Jak zmierzyć onboarding wtyczki, żeby zobaczyć, gdzie użytkownicy odpadają

Panele sklepów kończą się na instalacji i odinstalowaniu. Wszystko pomiędzy tymi dwoma zdarzeniami musi pochodzić z twojego produktu. Wysyłam pięć zdarzeń, a poniższe nazwy to moje zalecane nazwy, nie standard żadnej platformy ani narzędzia analitycznego:

Najważniejszą decyzją projektową jest definicja first_result. W plogins-customs pierwszym efektem jest dokument celny wygenerowany z prawdziwego zamówienia. W aplikacji do zestawów produktów w Shopify może to być pierwszy zestaw pokazany na stronie produktu. Zapisz to osobno dla każdego produktu, bo zdarzenie jest tylko tak dobre, jak jego definicja.

Minimalny szkic po stronie WordPressa wygląda tak. Endpoint i nazwa opcji są zmyślone, a nic nie jest wysyłane, dopóki właściciel witryny się nie zgodzi:

// Example only: endpoint and option name are placeholders.
function myplugin_track( string $event, array $props = [] ): void {
    if ( get_option( 'myplugin_telemetry_optin' ) !== 'yes' ) {
        return;
    }
    wp_remote_post( 'https://analytics.example.com/api/event', [
        'blocking' => false,
        'timeout'  => 2,
        'body'     => wp_json_encode( [
            'event'   => $event,
            'product' => 'myplugin',
            'version' => MYPLUGIN_VERSION,
            'props'   => $props,
        ] ),
        'headers'  => [ 'Content-Type' => 'application/json' ],
    ] );
}

add_action( 'myplugin_setup_saved', function () {
    myplugin_track( 'setup_completed', [ 'seconds_since_install' => time() - (int) get_option( 'myplugin_installed_at' ) ] );
} );

W darmowej wtyczce proszę o zgodę na ekranie konfiguracji, wyjaśniam, co jest wysyłane, i trzymam ładunek wolny od danych osobowych: bez adresów e-mail i bez adresów URL sklepów, chyba że użytkownik się na to zgodził. W Shopify backend aplikacji już zna sklep, więc zdarzenia idą po stronie serwera, z samej aplikacji.

Umami, PostHog i GA4 przyjmują zdarzenia własne. Wybieram jedno narzędzie na produkt i przy nim zostaję, bo zmiana narzędzia w środku porównania przed i po psuje to porównanie. Gdy pięć zdarzeń już płynie, tabela pomiarowa z drugiej sekcji wypełnia się sama, a lejek pokazuje, który z czterech punktów awarii z pierwszej sekcji cię dotyczy.

Mat De Sousa w tym samym poście dodaje jeszcze jeden argument za tą pracą: z jego doświadczenia sprzedawcy instalują konkurencyjne aplikacje obok siebie i zostawiają tę, którą najszybciej skonfigurować. Jeśli to pasuje do twojej kategorii, liczbą do obserwowania jest seconds_since_install przy zdarzeniu setup_completed.

#Jak zamienić wydania wtyczki w treści, które przyciągają użytkowników

Większość autorów wtyczek pisze changelog i na tym kończy. Changelog jest dokładny, krótki i prawie nikt go nie czyta. Zawarte w nim funkcje są za to najlepszym materiałem na treści, bo każda rozwiązuje konkretny problem, którego szuka właściciel sklepu.

Dla plogins publikuję maszynowo czytelny feed funkcji pod adresem plogins.com/features.json. Plik opakowuje wpisy w obiekt z polami vendor, count i releases. Każdy wpis wydania ma plugin, name, edition, version, released, url, changelog, wpOrg oraz listę features, w której każda pozycja ma kind (new, added lub changed) i text. Poprawki błędów i uwagi o bezpieczeństwie celowo są pominięte: ważne dla użytkowników, należą do changelogu, ale nie opisują nowej możliwości, której ktokolwiek szuka.

Oto prawdziwy wpis dla plogins-customs 1.3.0, wydanego 1 listopada 2026, skrócony do dwóch z pięciu funkcji:

{
  "plugin": "plogins-customs",
  "name": "Customs",
  "edition": "free",
  "version": "1.3.0",
  "released": "2026-11-01",
  "url": "https://plogins.com/plogins-customs/",
  "changelog": "https://plogins.com/plogins-customs/changelog/",
  "wpOrg": "https://wordpress.org/plugins/plogins-customs/",
  "features": [
    {
      "kind": "added",
      "text": "Customs Paperwork. Generate printable Commercial Invoice and Customs Declaration (CN22/CN23) slips directly from the WooCommerce order edit screen and order list."
    },
    {
      "kind": "added",
      "text": "Store EORI number setting under WooCommerce > EU Import Duty (Union Customs Code, Reg. (EU) No 952/2013, Art. 9), automatically printed on declarations and carrier export documents."
    }
  ]
}

Procedura, która zamienia taki wpis w treść:

1. Czytaj feed po każdym wydaniu. Mój workflow prasowy pobiera nowe wpisy i wylicza funkcje, które nie trafiły jeszcze do żadnego artykułu.
2. Przypisz każdą funkcję do problemu. “Customs Paperwork” odpowiada na pytanie sprzedawcy, jakich dokumentów wymaga paczka wysyłana poza UE. Ustawienie EORI odpowiada na pytanie, gdzie ma się znaleźć numer EORI.
3. Znajdź artykuł, który ten problem już opisuje. Jeśli istnieje, funkcja wchodzi do niego jako akapit z linkiem do wtyczki. Jeśli nie, problem staje się nowym artykułem.
4. Napisz to w każdej wersji językowej serwisu. Publikuję w sześciu językach, więc funkcja trafia do sześciu artykułów, każdego pisanego pod czytelników i przepisy krajów danego języka.
5. Podlinkuj z powrotem z wtyczki. Strona wtyczki i FAQ w readme linkują do artykułu wyjaśniającego problem, żeby osoba przychodząca z wyszukiwarki i użytkownik przychodzący z wtyczki trafiali na to samo wyjaśnienie.

Format feedu ma znaczenie z dwóch powodów. Skrypt potrafi go odczytać, więc przejście od wydania do szkicu nie zależy od tego, czy ktoś o nim pamięta. A ponieważ każda funkcja to jedno zdanie z polem kind, od razu widzę, które wydania dodały coś wartego opisania, a które tylko zmieniły zachowanie.

Jeśli chcesz wpiąć taki potok we własny proces wydawniczy i system treści, wchodzi to w zakres tego, co wdrażam jako go-to-market engineer. Strona automatyzacji, czyli haki wydań i zadania harmonogramowe, jest bliska pracy opisanej na stronie o automatyzacji procesów biznesowych.

#Czy konkurent może skopiować moją aplikację Shopify albo wtyczkę WooCommerce

Zdaniem Mata De Sousy z tego samego posta aplikacje będące tylko wizualną nakładką na sklep łatwo skopiować. Proponuje on dwa dodatki, które kopiuje się trudniej: warstwę usługową, w której dostawca konfiguruje aplikację za sprzedawcę, i warstwę danych, na przykład testy A/B i analitykę pokazującą sprzedawcy, co aplikacja zmieniła.

Moja praca potwierdza połowę o warstwie danych od strony klienta. Od 2019 roku prowadzę testy A/B, rekomendacje i treści dynamiczne w Dynamic Yield dla klientów e-commerce. Sprzedawcy, którzy widzą wynik testu powiązany z własnymi pytaniami o przychód, proszą o kolejny test. Sprzedawca, który widzi tylko widżet, pyta, czy nie ma tańszego widżetu.

Dla właściciela wtyczki lub aplikacji praktyczna wersja jest niewielka:

• Warstwa usługowa. Zaoferuj w planie płatnym rozmowę konfiguracyjną albo konfigurację “pod klucz” i pokaż to w listingu oraz na ekranie konfiguracji. W plogins-customs odpowiednikiem są wstępnie wypełnione ustawienia taryfowe i pochodzenia dla katalogu sprzedawcy.
• Warstwa danych. Pokaż sprzedawcy w produkcie jedną liczbę, która dowodzi, że wtyczka zadziałała: wygenerowane dokumenty, dodane pozycje celne, dostarczone maile. Ta liczba to także zdarzenie first_result z poprzedniej sekcji.

Mat De Sousa zaleca też szybkie przejmowanie nowych funkcji Shopify. Czytam to również jako argument o listingu: nowa możliwość platformy, którą twoja aplikacja obsługuje od pierwszego dnia, to nowa fraza wyszukiwania, nowy zrzut ekranu i nowy wiersz na liście funkcji.

#Czy Shopify Sidekick poleca aplikacje z App Store

Strona pomocy Shopify o Sidekicku dokumentuje, że Sidekick potrafi generować własne aplikacje, budować przepływy Shopify Flow i wykonywać zadania wieloetapowe. Strona nie podaje, że Sidekick poleca aplikacje z App Store.

Mat De Sousa opisuje to inaczej, ze swojego użycia: według jego relacji Sidekick zamienia pytanie sprzedawcy na hasła wyszukiwania i zwraca od 3 do 5 aplikacji z góry rankingu. To jego obserwacja, a Shopify jej nie udokumentowało.

Dwa wnioski zostają przy obu odczytaniach. Jeśli jego opis jest trafny, aplikacje, które dobrze wypadają w zwykłym wyszukiwaniu App Store, to te, które pokazuje Sidekick, więc praca nad listingiem opisana wyżej liczy się podwójnie. Jeśli Sidekick wygeneruje własną aplikację do prostej potrzeby, aplikacja pokrywająca tylko tę prostą potrzebę konkuruje z darmową, wygenerowaną alternatywą, a to wraca do warstwy usługowej i warstwy danych. Dopóki Shopify nie udokumentuje zachowania rekomendacji, nie planuję wokół niego żadnego startu.

#Od czego zależy pozycja wtyczki w WordPress.org i aplikacji w Shopify App Store

Żadna z platform nie publikuje wag swojego rankingu wyszukiwania. Strona readme na WordPress.org wyjaśnia, jak tagi i opisy są wyświetlane i filtrowane. Dobre praktyki Shopify wyjaśniają, jak wypełnić każde pole, a strona Built for Shopify mówi, że status daje podbicie w wyszukiwarce. Żadna z tych stron nie mówi, ile waży którekolwiek pole, recenzja czy liczba instalacji.

Ważenie Lighthouse ze strony dobrych praktyk Shopify (strona główna 17%, strona produktu 40%, kolekcja 43%) opisuje, jak Shopify łączy wynik wydajności dla różnych typów stron. To miara wydajności i żaden z trzech dokumentów nie wiąże jej z pozycją w wyszukiwarce.

Dlatego o wynikach mówię tak:

• Nikomu nie obiecuję pozycji w rankingu, sobie też nie.
• Mierzę to, co potrafię zdefiniować: wyświetlenia listingu, instalacje, ukończenie konfiguracji, pierwszy efekt, upgrade’y.
• Gdy po zmianie listingu przybywa instalacji, raportuję to jako zmianę w tym samym okresie, z wartościami przed i po, i trzymam równą długość okresów.

#Czy mogę wysyłać maile do osób, które zainstalowały moją wtyczkę

Wiadomości, które należą do usługi, jak klucz licencyjny, potwierdzenie konfiguracji albo informacja o bezpieczeństwie wtyczki, są częścią jej prowadzenia. Marketing kierowany do konkretnej osoby to inny przypadek i jest uregulowany.

W Polsce zasadę wyznacza art. 398 Prawa komunikacji elektronicznej (Dz.U. 2024 poz. 1221). Zakazuje on używania telekomunikacyjnych urządzeń końcowych do wysyłania informacji handlowej, w tym marketingu bezpośredniego, bez zgody odbiorcy. Pojęcie informacji handlowej definiuje ustawa o świadczeniu usług drogą elektroniczną. Warstwę unijną tworzy art. 13 dyrektywy 2002/58/WE o prywatności i łączności elektronicznej, który ustanawia tę samą regułę zgody w całej UE.

W praktyce, w przypadku użytkownika darmowej wtyczki, który niczego nie kupił, proszę o zgodę przy rejestracji, odznaczonym polem wyboru i zwykłym opisem tego, co dana osoba będzie dostawać. Nie opieram się na wyjątkach, bo zgoda zebrana na starcie zamyka temat dla darmowych użytkowników i dla klientów płacących. Jeśli rozważasz inną podstawę dla klientów już po zakupie, sprawdź ją w tekście ustawy, zanim zbudujesz na niej wysyłkę.

Na co dzień pracuję z Mauticiem na platformie subskrypcyjnej, a ustawienie, które działa, jest proste: jeden segment na produkt i plan, zbudowany z tych samych zdarzeń install, setup_completed i upgrade, oraz maile uruchamiane tym, co użytkownik zrobił lub czego nie zrobił. Użytkownik, który zainstalował wtyczkę, ale nigdy nie wywołał setup_completed, dostaje wiadomość o jednym ustawieniu, które blokuje konfigurację. Użytkownik, który doszedł do first_result, nie dostaje nic o konfiguracji. Dzięki temu maile są krótkie i na temat, a segmenty i tabela pomiarowa czytają z jednego strumienia zdarzeń.

#W jakiej kolejności pracować nad wtyczką lub aplikacją, której nikt nie używa po instalacji

To sekwencja, którą stosuję przy własnych produktach i polecam każdej wtyczce czy aplikacji z instalacjami i bez płacących użytkowników:

1. Tydzień 1: pomiar. Zdefiniuj pięć zdarzeń i warunek first_result, wdróż śledzenie ze zgodą i uzupełnij kolumnę Przed w tabeli pomiarowej z panelu sklepu i własnej analityki.
2. Tydzień 2: listing. Przejdź listę kontrolną pole po polu dla swojej platformy. Popraw tagi, krótki opis, frazy wyszukiwania, zrzuty ekranu i listę funkcji do udokumentowanych limitów. W produkcie na razie niczego nie zmieniaj.
3. Tygodnie 3 do 6: czytanie lejka. Daj zdarzeniom zebrać pełny okres. Znajdź krok z największym spadkiem: konfiguracja rozpoczęta, konfiguracja ukończona albo pierwszy efekt.
4. Tydzień 7: naprawa największego spadku. Skróć konfigurację, wstępnie wypełnij wartości domyślne albo przesuń pierwszy efekt bliżej instalacji. Jedna zmiana.
5. Tygodnie 7 do 10: ponowny pomiar. Uzupełnij kolumnę Po okresem o tej samej długości.
6. Przy każdym wydaniu: treści. Dodaj wydanie do feedu funkcji, przypisz każdą nową funkcję do problemu i artykułu oraz zaktualizuj wiersze z funkcjami w listingu.
7. Gdy lejek się ustabilizuje: kontakt mailowy. Zbuduj sekwencje maili oparte na zgodzie, na tych samych zdarzeniach.

W Shopify składaj wniosek o Built for Shopify po kroku 5, kiedy możesz pokazać liczby o konfiguracji i użyteczności, zamiast liczyć, że przegląd sam je znajdzie.

#Co zrobić teraz

Weź tabelę pomiarową z tego artykułu, uzupełnij kolumnę Przed dla swojej wtyczki lub aplikacji danymi z ostatnich czterech tygodni i wyślij ją do mnie razem z linkiem do listingu na WordPress.org albo w Shopify App Store przez stronę go-to-market engineer. Odpiszę przeglądem listingu pole po polu względem udokumentowanych limitów i jednym krokiem onboardingu, który zainstrumentowałbym jako pierwszy.