Case Study

Amazon Wishlist Scrapper – Jak pozyskać dane od dużych firm jeśli API na to nie pozwala

Budowanie produktu od zera zawsze jest wyzwaniem, ale jest to też nasza codzienna praca, więc zdążyliśmy już przywyknąć. Nie boimy się tworzyć i testować nowych rozwiązań i to właśnie zrobiliśmy w tym przypadku. Jeśli nie ma API pozwalającego na pobieranie danych zrobimy to na własny sposób. I o tym właśnie jest ta historia.

Nie pierwszy wybór

Kiedy nasz klient pojawił się u nas ze swoim pomysłem byliśmy podekscytowani. Wiedzieliśmy, że ten projekt przyniesie nam wiele wyzwań, a to właśnie kochamy robić – znajdować rozwiązania dla tych wyzwań. Jak zawsze zaproponowaliśmy zorganizowanie Product Design Workshop.

Niestety nie doszły one do skutku, ponieważ klient zdecydował się na współpracę z innym software housem. Ale nie na długo. Kilka miesięcy później odezwał się do nas ponownie i mogliśmy zacząć współpracę.

Pomysł

Nasz klient przyszedł do nas ze świetnym pomysłem, ale naszym zadaniem było sprawić, że on zadziała. Podczas Product Design Workshop omówiliśmy tematy takie jak model biznesowy, analiza konkurencji, wymagania techniczne, ale i tak najważniejszą częścią było ułożenie tych wspaniałych pomysłów w spójny proces.

Celem aplikacji było sprawienie by proces dawania prezentów był prostszy, szybszy i mniej niezręczny. Chcieliśmy dać użytkownikom możliwość połączenia się ze znajomymi i kupienia prezentu z ich listy życzeń. Chcieliśmy użyć istniejących już list na na znanych portalach takich jak Amazon, Walmart czy Target i przenieść je do naszej aplikacji. Brzmi prosto, prawda?

Pierwsze wyzwanie

Po szybkim researchu okazało się, że nie istnieje żadne API, które pozwalałoby nam pobrać listę życzeń z Amazona i udostępnić ją w naszej aplikacji. Oczywiście mogliśmy skontaktować się z Amazonem i poprosić o udostępnienie takich informacji, ale musielibyśmy pokazać im wartość takiego rozwiązania. A w tym momencie byliśmy tylko grupą obcych ludzi, którzy nie znaczyli nic dla tak dużej firmy.

Stwierdziliśmy więc, że zbudujemy scrapera, który będzie dla nas pobierał te informacje z ich platformy. Lista życzeń musiałaby być publiczna, użytkownik wklejałby do niej link, a nasz scraper kopiowałby zdjęcie, cenę, opis i odnośnik do produktu i wyświetlałby w naszej aplikacji. Oczywiście proces zakupowy wciąż odbywałby się poprzez platformę Amazona. 

Czy to jest legalne?

Na początek chcieliśmy przede wszystkim sprawdzić, czy używanie scrapera jest legalne. Poczytaliśmy trochę o sprawach sądowych odbywających się w tym temacie i większość z nich została wygrana przez twórców scraperów. Nie znaleźliśmy żadnego prawa zakazującego użytkowania ich.

Kiedy znajdujesz się w tzw. “szarej strefie”, zawsze warto zapytać samego siebie, czy moje działania nie wyrządzają nikomu krzywdy? Po przeanalizowaniu naszego procesu, doszliśmy do wniosku, że nasza aplikacja w żaden sposób nie zaszkodzi biznesowi innych platform. Co najwyżej może pomóc w zwiększeniu sprzedaży produktów wyświetlanych w naszej aplikacji. Więc daliśmy temu projektowi zielone światło.

Proof of concept

Podjęcie decyzji o stworzeniu scrapera wciąż nie rozwiązywało naszego problemu. Wciąż musieliśmy sprawdzić czy zadziała on w przypadku wybranych przez nas portali. Jeśli postanawiasz używać danych pochodzących od innych, musisz pamiętać, że jest wiele czynników, które mogą Ci w tym przeszkodzić.

Na przykład niektóre platformy posiadają zabezpieczenia przed atakami i wykrywają boty odwiedzające ich strony, przez co mogą je blokować. A nasz scraper był właśnie takim botem. Dodatkowo kiedy “nauczysz” takiego scrapera gdzie na stronie znajdują się zdjęcia i opisy produktów musisz liczyć się z tym, że wygląd strony może się z czasem zmienić, a scraper się pogubi.

Z tego powodu postanowiliśmy zacząć naszą pracę od POC (Proof of Concept), podczas którego mieliśmy się upewnić, że wszystko będzie działać zgodnie z naszymi założeniami. Zaangażowaliśmy dwóch deweloperów do pracy na czas 2-tygodniowego sprintu, aby to przetestować. W tym czasie stworzyliśmy scrapera dla Amazona i proces zapraszania znajomych. Dodatkowo poszczęściło nam się i znaleźliśmy świetną bibliotekę, którą wykorzystaliśmy do stworzenia front-endu naszej aplikacji, co pozwoliło nam przygotować ją do testów dla klienta. POC zakończyło się sukcesem.

Zbudujmy MVP

Jak zawsze, kiedy ekscytujesz się swoim projektem, może Ci się wydawać, że wszystkie funkcjonalności, które wymyśliłeś są niezbędne od początku istnienia aplikacji. Ważne żeby się w tym nie pogubić. Zaplanowaliśmy kolejny Product Design Workshop, stworzyliśmy i stworzyliśmy wstępne makiety dla wersji MVP.

Nie tylko klient wyszedł z gotowymi pomysłami, ale cały nasz zespół zaangażował się w proces burzy mózgów. Zdecydowaliśmy, że nie będziemy ograniczać się wyłącznie do platform, które posiadają już gotowe listy życzeń.

Co jeśli użytkownik znajdzie swój wymarzony prezent na innej stronie? Powinien mieć możliwość dodania go do swojej listy życzeń. A co jeśli zobaczy grę w domu swojego znajomego, ale nie będzie mu się chciało szukać jej w internecie? Powinien mieć możliwość dodania do listy produktu jako zwykłe zdjęcie.

Na podstawie tych i kilku innych pomysłów postanowiliśmy zbudować w aplikacji wewnętrzną przeglądarkę, która będzie w stanie pobierać dane ze wszystkich możliwych stron internetowych za pomocą przycisku “add to wishlist”. Pojawiło się również kilka pytań typu co jeśli ktoś już zakupił dany prezent z listy, czy skąd użytkownik ma wiedzieć na jaki adres wysłać przesyłkę. Na wszystkie te pytania stworzyliśmy rozwiązania, które możesz sprawdzić pobierając naszą aplikację 😉 (https://beri.gifts/)

Zespół i organizacja

W tym projekcie naszym Product Ownerem został nasz klient. Nie był on osobą techniczną, ale miał jasno sprecyzowane oczekiwania co do tego jak ma wyglądać jego aplikacja. Zarezerwowaliśmy dwóch Fullstack Deweloperów – jeden z nich wolał pracować nad back-endem, drugi nad front-endem. Dzięki temu każdy z nich mógł się skupić na swojej części pracy, ale wciąż mogli pomagać sobie nawzajem w przypadku jakichkolwiek blokad.

Dodaliśmy również Customer Success Managera, który upewniał się, że wszystko przebiega zgodnie z planem, deweloperzy rozumieją cele biznesowe klienta i nie ma problemów komunikacyjnych między zespołem deweloperskim a klientem.

I na koniec nasz Project Supervisor, który zajmował się szeroko pojętą organizacją, jak również budżetami i estymacjami. Właściwie wszystkim tym, za czym w projektach nie przepadamy, ale bez czego współpraca nie przebiegłaby gładko.

Zaplanowaliśmy pracę na 5 tygodniowych sprintów. Co tydzień odbywały się spotkania pozwalające na przeanalizowanie pracy jaką udało nam się wykonać i zaplanowanie pracy na kolejny tydzień (Review/Retro/Planning), oraz codzienne spotkania statusowe (Daily meetings). Nasz klient pojawiał się na każdym z tych spotkań, dzięki czemu nasza praca stawała się dużo prostsza.


Designy

Ponieważ zawsze staramy się dostarczać naszym klientom “pełen zestaw” brak identyfikacji wizualnej firmy i widoków dla aplikacji nie był tu problemem. Klient dostarczył nazwę firmy i logo i resztę zostawił w naszych rękach. Nasz grafik zaczął od przygotowania 3 widoków inspirowanych wyglądem stron, które klient nam podesłał. Gdy podjęliśmy decyzję o wyglądzie aplikacji przeszliśmy do projektowania każdego z widoków.

Nasz grafik skupił sie również na UX/UI, więc musieliśmy momentami wprowadzić poprawki w naszym procesie. Niektóre z widoków zostały uproszczone, dodaliśmy również modale, o których nie pomyśleliśmy wcześniej. Każdy z nas był zadowolony z finalnego wyglądu. Pomogliśmy klientowi również w stworzeniu prostego landing page’a, aby pasował on wyglądem do wyglądu aplikacji.

You shall not pass!

Udało nam się dostarczyć aplikację na czas. Moment był świetny, ponieważ działo się to w trakcie pandemii i pierwszego lockdownu. W związku z tym nasza aplikacja rozwiązywała problem dawania prezentów, gdy każdy musiał przebywać w swoim domu.

Na początek nasz klient przetestował aplikację wraz ze swoimi znajomymi. Po kilku poprawkach byliśmy gotowi oficjalnie wypuścić produkt. I zazwyczaj tutaj kończy się nasza praca. W sklepie Google aplikacja pojawiła się od razu, ale Apple nie był zadowolony z naszego rozwiązania. Nie tylko nasz klient był zagubiony, my też! Podczas 10 lat naszej pracy nad aplikacjami nigdy nie mieliśmy tylu problemów z wypuszczeniem naszej pracy.

To nie było coś co mogliśmy naprawić linijką kodu, ponieważ Apple miał problem z samą logiką naszej aplikacji i… faktem, że korzystamy z danych pobieranych od Amazona i innych platform.

Przez moment byliśmy szczerze przerażeni tym co będzie dalej. Nasz klient chciał przepisywać połowę aplikacji, żeby sprostać wymaganiom Apple, ale udało nam się go powstrzymać. Musieliśmy tylko przekonać Apple, że to my mamy rację. 🙂 Po długiej wymianie zdań i milionie wytłumaczeń udało się! Możesz znaleźć naszą aplikację w obu sklepach i wysyłać swoim znajomym prezenty o jakich zawsze marzyli!

Podoba ci się ten artykuł? Podziel się nim ze swoimi przyjaciółmi:
Autor:

Patrycja Jach

Napisz do mnie: p.jach@gmihub.com

Więcej case studies