W dotychczasowych tekstach skupiałem się zwykle na opisywaniu realiów naszej pracy i branży ogólnie. Dziś mam Wam do zaproponowania nieco inny artykuł. W tym tekście pozwolę sobie trochę poteoretyzować i puścić nieco wodze fantazji. Znacie to uczucie, kiedy zagracie kupon w lotka i aż do losowania możecie sobie w myślach powydawać niewygrane jeszcze pieniądze? Takie też uczucie towarzyszyło mi w ostatnich miesiącach, kiedy rozmyślałem sobie o tym, jakie rozwiązania zastosowałbym w idealnej apce delivery. Rozwiązania, które pozwoliłyby żeby system działał dobrze, a jednocześnie były bardziej praktyczne dla samych dostawców jedzenia. Przechodząc do meritum, chciałbym Wam dziś opowiedzieć o moim pomyśle na lepiej działające mnożniki. Temat powinien brzmieć pewnie Teoria Super Mnożnika, ale jak już zdążyliście pewnie zauważyć, lubię bawić się w przerabianie tytułów filmów, czy też różnych powiedzonek. Mnożnik pozostał więc w tytule wielki – choć taki wcale być nie musi.
Składowe zarobków kuriera
Oczywiście zdaję sobie sprawę, że mojego bloga czytają głównie koleżanki i koledzy po fachu. Wiem jednak, że trafia on też do osób spoza branży, więc na początek skrótowo przedstawię w jaki sposób skonstruowane są stawki za dostawy w większości aplikacji.
To, ile kurier zarobi za daną dostawę zależy od kilku czynników. Pomijając Pyszne.pl (które ma zupełnie inny system wynagradzania kurierów, więc to co dziś piszę ich zupełnie nie dotyczy), w każdej aplikacji podstawową opłatą jest tak zwana baza. To opłata za hipotetyczną dostawę, w której klient i kurier znajdowaliby się w restauracji, z której klient zamawia. Niektóre aplikacje rozbijają jeszcze bazę na oddzielną opłatę za odbiór jedzenia z aplikacji i dostarczenie jej klientowi. Tak czy siak ich suma określana jest bazą. Drugim składnikiem w każdej aplikacji jest tak zwana kilometrówka. W skrócie opłata za dystans pokonany przez kuriera. Jedne apki płacą za całą trasę pokonaną od punktu przyjęcia zamówienia, poprzez restaurację, aż do klienta. Inne natomiast tylko za trasę od restauracji do momentu dostarczenia jedzenia.
Do tego dochodzi trzeci składnik, który wpływa na opłatę za dostawę. Występuje on w każdej firmie poza Wolt (choć i u nich w pewnym sensie może się czasem pojawić). Jest to bohater dzisiejszego tekstu – czyli mnożnik. Konkretnie mówiąc jest to współczynnik określający o ile % podniesiona zostaje opłata za kursy w danym czasie, czy miejscu. Przedstawia się go zwykle w formie na przykład x1.3, co oznacza podniesienie zapłaty o 30%. Jeśli kurier zrobi kurs gdzie 5zł stanowiła baza, kolejne 5 wyszło za kilometrówkę i ma mnożnik x1.3, to zamiast 10 złotych zarobi 13. Wyjątkiem jest tu Stuart, który daje mnożnik tylko na kilometrówkę.
Dla formalności dodam, że do naszych zarobków MOGĄ dochodzić bonusy, za określoną liczbę kursów, a także – równie mile widziane, co rzadko otrzymywane – napiwki.
Po co aplikacjom mnożniki?
Podstawową funkcją mnożnika jest minimalizowanie ryzyka wystąpienia sytuacji, w której zamówienie musi zostać anulowane z powodu braku dostępnych kurierów. Współczynnik realizacji zleceń jest bez wątpienia jedną z najbardziej istotnych kwestii dla firm z branży food delivery. Wystarczy postawić się w sytuacji człowieka, który chciałby coś zjeść, składa zamówienie, a po kilkudziesięciu minutach dowiaduje się, że tego jedzenia nie dostanie. „Polak głodny – Polak zły” głosi znane powiedzonko i – co tu dużo mówić – mało jest powiedzonek równie celnych, jak to. Istnieje ogromne prawdopodobieństwo, że takie zamówienie będzie ostatnim jakie dany klient złoży na danej platformie. Jeszcze większy problem robi się, jeśli dana firma sprzedała klientowi abonament na darmowe dostawy. Niedostarczenie posiłku w takim wypadku, staje się nawet podstawą do złożenia skargi w UOKiK. Przekonał się o tym ponoć Wolt pod koniec zeszłego roku.
Głównym zadaniem mnożników jest więc sprawienie, że w danym miejscu i czasie będzie odpowiednia liczba kurierów. Tam gdzie pracownicy działu operacyjnego aplikacji mają podejrzenie, że może być problem z realizacją zamówień, dają większe mnożniki. Tam gdzie problemów być nie powinno – mniejsze. W ostatnich dniach dochodzą do nas informacje, że w niektórych krajach Uber Eats przekazał ustalanie mnożników i bonusów sztucznej inteligencji. Nie wiem jednak na ile są to wiarygodne informacje. Z pewnością w Polsce póki co żadna aplikacja nie pozostawiła tego zadania AI. Mnożniki są zbyt stabilne i przewidywalne dla doświadczonych kurierów, żeby w ich układaniu nie brał udziału człowiek. Niemniej bez wątpienia w każdym zespole zajmującym się tym zagadnieniem, z pewnością decyzje te oparte są na głębokiej analizie danych.
W jaki sposób ustalane są mnożniki
W tym miejscu należałoby zadać sobie pytanie, jakie dane są analizowane w procesie ustalania mnożników. Oczywiście mogę tylko domniemywać które. Domyślam się też, że strategie w tym temacie mogą różnić się w poszczególnych firmach. Niemniej spróbujmy się zastanowić co w tej materii może najbardziej interesować pracowników zespołów operacyjnych w aplikacjach food delivery.
Przeglądając tabelki z mnożnikami w różnych aplikacjach jesteśmy w stanie zauważyć co najmniej trzy płaszczyzny powtarzających się schematów. Dwie z nich dotyczą czasu, a trzecia przestrzeni.
Pory dnia
Jakie są zależności?
Pierwsza płaszczyzna to czas w skali doby. Można by tu dodać jeszcze skalę tygodnia, bo w weekendy wygląda to nieco inaczej niż w dni robocze. Nie komplikujmy już może tego i skupmy się na skali dobowej w dniach roboczych. Bez wątpienia w ciągu dnia są pory, w których zamówień jest zdecydowanie więcej niż w innych godzinach. Mam tu na myśli dwa bloki. Pierwszy z nich to pora lunchowa (z grubsza 12-14), a druga to późne popołudnie, czy też wczesny wieczór – jak zwał, tak zwał. Chodzi o godziny od 17 do 20. W pozostałych godzinach zamówień jest mniej lub znacznie mniej.
Gdyby aplikacje ustalały mnożniki wyłącznie na podstawie liczby dostępnych zamówień, wówczas dość szybko wpadłyby w pułapkę. O ile zasadnym jest danie wyższych mnożników dla godzin szczytowych, o tyle nie można lekceważyć tych godzin, w których mało jest nie tylko zamówień, ale też kurierów. Takimi okresami są godzinny poranne i późny wieczór/noc. W tych godzinach zdecydowana większość kurierów albo jeszcze nie wychodzi do pracy (rano), albo już wróciła do domu (późny wieczór). Aby namówić jednak kogoś do pracy, aplikacje najczęściej zmuszone są i tam zwiększyć mnożniki.
Pory, w których mogą sobie pozwolić na niższe stawki, to pory w których zamówień jest mniej, ale kurierzy są już na ulicach. Takimi porami są przede wszystkim dwa bloki. Ten poprzedzający porę lunchową, godziny 10-12, kiedy już część dostawców wyrusza na miasto, a zamówień wciąż jeszcze jest mało. Przede wszystkim jednak pora pomiędzy godzinami szczytu – czyli z grubsza 15-17. Wtedy kurierzy jeżdżący więcej – nazwijmy ich etatowymi – i tak zwykle jeżdżą czekając na drugi lepszy moment dnia.
Co z tego wynika?
Aby ustalić mnożniki aplikacje muszą więc brać pod uwagę nie tylko samą liczbę zamówień. Wydawałoby się, że powinny więc brać pod uwagę liczbę dostępnych zamówień, w porównaniu do liczby zalogowanych w danym miejscu i czasie dostawców. Takie podejście mogłoby jednak być bardzo zwodnicze. To, że kurier jest on-line, nie znaczy wcale, że będzie przyjmował zamówienia. Nawet jeśli odsiać z analizy kurierów wykonujących aktualnie kursy – ci teoretycznie wolni kurierzy mogą nie brać kursów z wielu powodów. Chociażby przez wzgląd na to, że robią w tym czasie zamówienia z innych aplikacji, czy też czekają na korzystniejsze kursy dla siebie, robią zakupy, jedzą obiad etc. Oczywiście można liczbę wolnych kurierów brać pod uwagę przy szacunkach. Moim zdaniem jednak, akurat ta zmienna powinna mieć – przy obecnych systemach – dość małe znaczenie.
Bardziej istotna byłaby tu zapewne analiza danych z ostatnich tygodni. Należałoby się przyjrzeć danym dotyczącym wskaźnika realizacji zamówień, ale też podobnego wskaźnika dotyczącego znacznych opóźnień w realizacji zamówienia. Jakby nie było opóźnione dostawy to również niepożądana sytuacja. Mogą na nią jednak wpływać kwestie niezależne od aplikacji. Z tego względu dostawy opóźnione powinny mieć niższą wagę w obliczeniach, niż zamówienia niezrealizowane.
Pory roku
Druga płaszczyzna to czas w skali roku. O sezonowości pracy w branży food delivery pisałem Wam już dwa lata temu. Co do zasady w miesiącach ciepłych jest mniej zamówień niż w zimnych. Przede wszystkim jednak zdecydowanie więcej gotowych do pracy kurierów. Zimą (szczególnie na przełomie listopada i grudnia) sytuacja się odwraca. Zamówień jest więcej niż kurierów gotowych je rozwozić. W efekcie oczywiście mnożniki w aplikacjach sięgają swoich szczytów właśnie w tym okresie. Później systematycznie spadają aż do lata, kiedy docierają do najniższych w skali roku wartości.
Strefy
Co jest istotne?
Trzecia, a zarazem najmniej stabilna płaszczyzna do analizy mnożników to przestrzeń. Liczba zamówień oczywiście nie rozkłada się na terenie miast równomiernie. Oczywiście ta zmienna istotna jest w przypadku dużych miast. Mniejsze miejscowości mogą raczej mieć jedną strefę. To co w tym kontekście jest najistotniejsze, to nie tyle sama informacja gdzie mieszka najwięcej osób. Interesuje nas raczej to gdzie jest najwięcej restauracji z zamówieniami na aplikacji. Jak łatwo się domyślić, największa liczba restauracji znajduje się w tzw centralnych dzielnicach, szczególnie tych mających charakter turystyczny i biurowy. Tam też znajdują się w większej liczbie restauracje „modne”, z których ludzie są skłonni zamawiać jedzenie nawet z długim dojazdem. Im dalej od Centrum tym mniej jest restauracji, ale też ich działalność jest bardziej lokalna. Spotykamy tam głównie małe osiedlowe knajpki, lub restauracje sieciowe, które znajdują się po prostu w każdym rejonie miasta.
Kurierzy rzecz jasna dość szybko zdają sobie sprawę, że najwięcej zamówień jest w dzielnicach centralnych i w dużej części tam właśnie kierują się w poszukiwaniu zleceń. Jeśli szukać więc wzoru jaki rysuje się w kwestii zapotrzebowania na kurierów w danych strefach, zazwyczaj wyjdzie nam, że najmniejszy problem z zapewnieniem zleceniom dostawców jest w tych dzielnicach, które nie znajdują się w ścisłym Centrum, ale też nie leżą na obrzeżach.
Dodatkowe komplikacje
Sytuacja w tej płaszczyźnie jak wspomniałem jest jednak najmniej stabilna. Pomijam już rozwój poszczególnych stref. Powstające w ogromnych ilościach nowe osiedla, czy też centra handlowe i ogólnie rozwijająca się scena gastronomiczna w danych dzielnicach. Znaczenie ma tu chociażby pora roku. Zimą zamówień jest ogólnie dużo i nawet będąc dalej od Centrum kurierzy mogą być względnie spokojni o ciągłość pracy. W tym okresie nie muszą oni kierować się do dzielnic, z większą liczbą zamówień, bo często mają je nawet na obrzeżach. Co więcej, zimą udział dostawców samochodowych jest zdecydowanie większy niż w pozostałych porach roku. Kurierzy korzystający z tego rodzaju pojazdu, najczęściej niezbyt chętnie udają się do stref centralnych. Tam borykali by się z korkami i problemami z parkowaniem. W efekcie w tym czasie aplikacje powinny wzmacniać mnożnikami przede wszystkim właśnie te – centralne – dzielnice.
Latem natomiast liczba dostępnych kurierów jest zdecydowanie większa. Jeśli chcą zarobić, muszą szukać miejsc, gdzie będą mieli – kolokwialnie mówiąc – co wozić. W ciepłym okresie też zdecydowanie rośnie udział dostawców rowerowych. Dla nich korki i parkowanie nie mają żadnego znaczenia. Największy problem więc dla aplikacji zaczynają stanowić dzielnice znajdujące się w mniej korzystnych lokalizacjach. Mimo, że samych zamówień jest tam bardzo mało, to kurierzy najczęściej unikają tych miejsc jak ognia.
Paradoks aktualnych mnożników
Co ciekawe, największy problem z realizacją, mają w tym okresie niekoniecznie zamówienia z restauracji w tych dalekich dzielnicach. Największy problem jest z zamówieniami z restauracji w najlepszych dzielnicach, które jednak złożyli klienci mieszkający w tych kiepskich dla dostawców miejscach. W większości przypadków, dla kuriera ważniejsze jest nie to z jakiej strefy odbiera zamówienie, a to gdzie wyląduje po jego zakończeniu. Mało kto będzie chętny wyjeżdżać ze strefy, w której może być względnie spokojny o kolejne kursy. Szczególnie jeśli aplikacja kieruje go do dzielnic z których pewnie będzie wracał na pusto. Paradoksalnie może dochodzić do sytuacji, w których zamówienia nie są realizowane, lub są poważnie opóźnione, mimo że na mieście jest satysfakcjonująca aplikację liczba kurierów.
I to jest właśnie ten moment, w którym wjeżdża cały na biało mój Super mnożnik 🙂
Teoria Super Mnożnika
Wszystkie aplikacje, które stosują mnożniki ustalają je dla strefy, w której znajduje się restauracja. Moim zdaniem mnożniki powinny zależeć zarówno od miejsca odbioru, jak i miejsca dostawy. Super mnożnik miałby więc dwie wartości, których suma decydowałaby ostatecznie o wartości „doładowania” wyceny danego kursu. Oczywiście kurier znałby obydwa mnożniki przed rozpoczęciem dostawy.
Część restauracyjna
Jeśli chodzi o część „restauracyjną” mnożnika to brałbym tu pod uwagę dwa rozwiązania. Jedno – bezpieczniejsze – to z grubsza podobny sposób naliczania do tego, jaki funkcjonuje obecnie. Ja bym tu użył przede wszystkim danych takich jak liczba zamówień z restauracji w danej strefie i procentowy wskaźnik realizacji tych zamówień. Do tego w mniejszym stopniu wskaźnik zamówień opóźnionych i liczba wolnych kurierów.
Druga opcja bardziej ekscytująca, ale i bardziej ryzykowna, to dynamiczne mnożniki dla strefy odbioru. Opcja ta zakłada uzależnianie części „restauracyjnej” mnożnika, od sytuacji która ma miejsce w danej strefie w czasie rzeczywistym. W tym przypadku w znacznie większym stopniu można byłoby się oprzeć na stosunku aktualnych i przewidywanych w najbliższym czasie zamówień w porównaniu do liczby dostępnych, lub wkrótce dostępnych w strefie kurierów. Oczywiście wciąż nie można by było zakładać, że każdy kurier będący on line, będzie gotowy i chętny do brania zamówień.
Należałoby ustalić pożądaną nadwyżkę dostawców, porównując dane z minionych tygodni. Najlepiej chyba to zrobić w oparciu o porównanie współczynnika realizacji zamówień w danej strefie do liczby dostawców on-line w analogicznych porach dniach i tygodnia. Tę kwestię, a także zakresy mnożnika w ramach którego operowałby algorytm ustalałby człowiek. W ten sposób uniknęlibyśmy błędów wynikających z jakiś chwilowych anomalii. Na przykład żeby, w związku z chwilowym znacznym nadmiarem kurierów, mnożnik nie spadał spadałby za nisko, lub przeciwnie – w wyniku chwilowego braku kurierów nie rósł za wysoko. Ponadto człowiek wybierałby zakres mnożników adekwatnie do pory roku, spodziewanej pogody, czy specyfiki dni szczególnych (walentynki, święta, demonstracje, maratony etc.).
Osobiście mam wątpliwości, czy mnożnik restauracyjny powinien się zmieniać w stu procentach na bieżąco. Raczej ustaliłbym jakiś rytm zmiany tej części mnożnika. Wstępnie wydaje mi się, że aktualizacje co pół godziny byłyby w sam raz. Jest to z grubsza czas nieco większy od czasu przeciętnej dostawy.
Część klienta
Część „klientowska” mnożnika byłaby natomiast ustalana z góry co tydzień. W tej części docelowo promujemy strefy, do których kurierzy zapewne mniej chętnie się udadzą. Ta kwestia nie będzie się raczej zmieniać w krótkiej perspektywie czasu. Jakie dane nas tu przede wszystkim interesują? Z pewnością jest to ogólna liczba spodziewanych zamówień. Im mniej ich jest, tym większy mnożnik. Bralibyśmy pod uwagę także wskaźnik zrealizowanych i znacznie opóźnionych zamówień kończących się w danej strefie.
Spodziewane efekty
Super mnożnik spowodowałby moim zdaniem znaczącą poprawę wskaźników realizacji zamówień i zamówień opóźnionych. Kursy, najbardziej narażone na trudności z realizacją – czyli te z dobrych stref, do tych kiepskich – miałyby siłą rzeczy najwyższe mnożniki. Wynikałyby z tego, że zarówno mnożnik strefy odbioru, jak i klienta byłyby wysokie. Kurier, który trafiłby do kiepskiej strefy i dostał tam kolejne, ale tym razem lokalne zamówienie, wciąż miałby niezłą stawkę. Co prawda niższą niż za kurs, który tam go skierował, bo mnożnik restauracyjny byłby najpewniej niski, ale mnożnik klienta wciąż byłby przecież wysoki. Gdyby dostał kurs zbliżający go ponownie do dobrych stref, to i tak chciałby go wziąć, mimo że dany kurs byłby za mniejsze kwoty. Na moim własnym przykładzie mogę powiedzieć, że kiedy jeżdżę rowerem i mam kurs ze swojej (raczej kiepskiej strefy), do Centrum, to drugorzędne dla mnie jest ile za niego dostanę. Cieszę się z niego, bo będę miał zapłacone za trasę, którą i tak pokonałbym za darmo.
Wyznaczanie stref
Istotną kwestią jest tu też samo wyznaczenie stref. Oczywiście najłatwiej jest zrobić tak jak Bolt, czyli po granicy poszczególnych dzielnic. Ma to taką zaletę, że kurierzy z grubsza wiedzą, gdzie znajdują się granice dzielnic, po których najczęściej się poruszają. Minus jest taki, że obszary w ramach jednej dzielnicy mogą się drastycznie od siebie różnić. W ten sposób łatwo doprowadzić do sytuacji, że kursy zasługujące na szczególną uwagę, są po zbyt niskiej cenie, bo dzielnica jako całość ma niski mnożnik. Może też wyjść odwrotnie i restauracje, które łatwo obsłużyć mają wysokie mnożniki, bo w innej części dzielnicy są one niezbędne. Lepszy system ma Uber Eats, który ma strefy podobne do rzeczywistych granic dzielnic, ale jednak zdarzają się tam przesunięcia całych fragmentów, do sąsiedniej – bardziej podobnej do danego miejsca dzielnicy.
Najlepszym przykładem będzie tu warszawska dzielnica Wola. Wschodnia część tego rejonu Warszawy znajduje się de facto w ścisłym Centrum. Jest ona po prostu jednym z najważniejszych hotspotów w mieście. Zachodnia część Woli to raczej dzielnica, do której pasują najniższe mnożniki. Jest to typowa strefa przejściowa. Ani obrzeża, ani Centrum. Zaspokojenie zapotrzebowania na kurierów jest tam zdecydowanie łatwiejsze, niż trudniejsze. Uber przesunął więc wschodnią część Woli do Centrum. Zachodnią zaś połączył z Jelonkami. Osobiście, gdybym miał o tym decydować, również oddzieliłbym wschodnią część Woli i przeniósł ją do Śródmieścia. Granicę postawiłbym jednak wcześniej już na ulicy Płockiej, a nie Prymasa Tysiąclecia tak jak to zrobił Uber. Kategorycznie natomiast nie łączyłbym zachodniej Woli z Jelonkami. Te co do zasady bardziej podobne są do dzielnicy, do której administracyjnie należą, czyli Bemowa.
Nieco więcej stref
Mając dynamicznie zmieniający się mnożnik, nie możemy ustalać zbyt dużych stref. Ważniejsze jest by dany obszar miał jednolity potencjał w delivery. W moim hipotetycznym systemie byłoby więc nieco więcej stref, aczkolwiek na pewno chciałbym uniknąć sytuacji gdzie byłoby ich za dużo. W praktyce byłoby pewnie o kilka więcej niż na Uberze.
Zastrzeżenia
Skoro już odnoszę się w moich rozważaniach do Ubera, to trzeba tu zaznaczyć, że mój system tam by nie mógł (na chwilę obecną) zaistnieć. Wynika to z faktu, że Uber w Polsce nie pokazuje miejsca docelowego w momencie akceptacji zamówienia. W Bolt Food natomiast, być może już na wstępie wyliczenia wyszłyby inaczej, niż w moich założeniach. Estońska apka od jakiegoś czasu płaci bardzo dobrze i zapewne nie ma większych problemów z realizacją zamówień. Widać to chociażby po dostępności zleceń dla kurierów na tej apce. Skutkiem takiego stanu rzeczy jest to, że zapewne w wyniku analizy danych z ostatnich tygodni wyszło im, że w ich przypadku należałoby wzmocnić mnożniki z centralnych dzielnic kosztem całej reszty. Nie muszą doładowywać obrzeży, bo i tak zamówienia im tam schodzą.
Jeszcze inna sytuacja ma miejsce w Glovo i Stuart. Tam mnożniki są po to by, zapełniać grafiki godzinowe. Aplikacje analizują więc zapewne głównie stopień zapełnienia i realizacji poszczególnych slotów w danych strefach. Kurierzy w zasadzie nie mają – a jeśli mają to iluzoryczne – możliwości przebierania w kursach. Realizują więc z grubsza, to co im wpadnie. W tych apkach z grafikiem i obowiązkiem realizowania większości kursów, taki system jak ja proponuję, nie ma racji bytu.
Zakończenie
Na koniec chciałbym podkreślić, że system ten przede wszystkim tworzyłem przy okazji rozważań o hipotetycznej idealnej apce. W związku z tym nie należy – choć można – rozpatrywać go jako coś do zaimplementowania do obecnych aplikacji. Gdyby ktoś chciał go sobie wyobrazić w obecnej apce, to zastrzegam tu, że doskonale rozumiem, że przez wzgląd na doświadczenia ostatnich kilku lat na delivery, informacje o jakichkolwiek zmianach wywołują w kurierach (szczególnie woltowskich) odruch obronny. Ostatecznie zmiany w aplikacjach często kończą się tym, że przy okazji ucina się po prostu pulę przeznaczoną na wynagrodzenia dla kurierów. Warto więc pamiętać, że w takich przypadkach bardzo często nie sama zmiana jest zła, tylko sposób w jaki ją przeprowadzono.
Zachęcam Was też do myślenia o tym w kategoriach systemu, a nie tego, jak by wyglądały Wasze zarobki przy obecnym stylu pracy. W oczywisty sposób dla niektórych kurierów dwuskładnikowy system nie wyszedłby na dobre. Jeśli ktoś preferuje trzymanie się swojej wygodnej dzielnicy, która dodatkowo jest dzielnicą przejściową, to będzie miał dość niskie mnożniki. Dla systemu istotne jest to, aby jak najmniej kursów było opóźnionych, a przede wszystkim anulowanych, premiowane są więc przede wszystkim kursy „niewygodne”.
kostor
Jeśli moje teksty pomogły Ci, albo po prostu uważasz je za wartościowe, możesz wesprzeć mnie za pomocą powyższego guzika:)