Automatyzacja wyszukiwania firm i mailingu: architektura, ryzyka i lekcje z prototypu

Pierwsza decyzja była prosta: lista firm ma pochodzić z oficjalnego API, a nie ze scrapowania widoku mapy. To ważna granica. System nie udaje przeglądarki, nie klika po Google Maps, nie obchodzi zabezpieczeń i nie próbuje masowo pobierać danych z interfejsu przeznaczonego dla człowieka.

Źródłem kandydatów jest oficjalne Google Places API. Z niego można uzyskać podstawowe dane firmy: nazwę, adres, telefon, link do profilu oraz, jeśli jest dostępna, stronę WWW. Dopiero ta strona WWW staje się miejscem dalszej analizy.

To zmienia charakter całego rozwiązania. Nie budujemy agresywnego scrapera. Budujemy proces, który korzysta z oficjalnego źródła do znalezienia firm, a potem sprawdza publicznie dostępne strony tych firm w poszukiwaniu ogólnych danych kontaktowych.

Sama obecność firmy w katalogu nie oznacza jeszcze, że mamy dobry kontakt. W prototypie ważnym etapem było wejście na publiczną stronę WWW firmy i sprawdzenie, czy znajduje się tam adres e-mail.

W praktyce to nie jest banalne. Strony firm są bardzo różne. Jedna ma czytelne „kontakt@” w stopce. Druga ma formularz bez adresu. Trzecia ma kilka adresów: biuro, serwis, sprzedaż, rekrutacja. Czwarta nie działa, przekierowuje albo odpowiada zbyt wolno. Piąta publikuje adres imienny, który nie zawsze powinien być użyty w pierwszym kontakcie biznesowym.

Dlatego prototyp nie zapisuje jedynie wartości „e-mail znaleziony”. Ważne jest również źródło: adres strony, z której e-mail został pobrany. Bez tego trudno później ocenić jakość danych, poprawić reguły wyboru albo wyjaśnić, skąd kontakt pojawił się w bazie.

Jedną z ciekawszych obserwacji była skuteczność prostego, ostrożnego podejścia. W badanej próbie około dwie trzecie firm posiadających stronę WWW miało możliwy do zapisania adres e-mail. W lokalnym eksporcie było to 50 z 79 stron, czyli 63,29%.

To nie jest gwarancja dla każdej branży ani każdych danych wejściowych. Wynik będzie zależał od profilu firm, regionu, jakości stron i sposobu, w jaki firmy publikują dane kontaktowe.

W prototypie dane nie kończą życia w pamięci skryptu. Trafiają do lokalnej bazy SQLite oraz do pliku CSV, a opcjonalnie mogą być eksportowane do arkusza Google Sheets. Każda z tych warstw ma inną rolę.

• SQLite — historia, statusy i deduplikacja
• CSV — szybki podgląd, eksport i awaryjna analiza
• Arkusz Google — interfejs dla człowieka: filtrowanie, przeglądanie, komentarze

To rozdzielenie jest zdrowe. Arkusz nie musi być jedyną bazą prawdy. Baza danych nie musi być jedynym miejscem pracy człowieka. CSV nie musi udawać systemu CRM. Każde narzędzie robi swoją część roboty.

W systemach leadowych duplikaty pojawiają się szybciej niż kurz na czarnym monitorze. Ta sama firma może zostać znaleziona przez różne zapytania, może mieć kilka wariantów nazwy, kilka adresów URL albo ten sam e-mail na kilku podstronach.

Dlatego deduplikacja nie może opierać się wyłącznie na jednym polu. Sensownie jest porównywać kilka sygnałów: nazwę i adres, stronę WWW, link do profilu, e-mail oraz inne stabilne identyfikatory.

Jedna z najważniejszych decyzji architektonicznych: wyszukiwanie leadów i wysyłka e-maili są rozłączone. System nie wysyła wiadomości automatycznie w momencie znalezienia adresu. Kampania jest osobnym, ręcznie uruchamianym procesem, domyślnie z trybem podglądu.

To bardzo dobra granica bezpieczeństwa. Dane znalezione automatycznie powinny najpierw przejść przez filtr: branża, region, status, typ adresu, wcześniejsze wysyłki i sensowność kontaktu. Dopiero potem można myśleć o wiadomości.

Wysyłka powinna mieć limity dzienne, historię, statusy i zabezpieczenie przed ponownym kontaktem do już obsłużonych rekordów. Właśnie ta część oddziela narzędzie wspierające pracę od automatu, który nie wie, kiedy przestać mówić.

Najwięcej pracy w takim projekcie nie zawsze siedzi w algorytmie wyszukiwania. Często siedzi w konfiguracji usług zewnętrznych.

Potrzebne są klucze API, uprawnienia w Google Cloud, dostęp do Google Sheets, konto usługowe, konfiguracja Gmail API albo SMTP, nadawca wiadomości, adres odpowiedzi, limity, zakresy uprawnień i pliki konfiguracyjne. Każdy z tych elementów może się zepsuć osobno. Każdy może też stać się ryzykiem bezpieczeństwa.

W prototypie każdy rekord może mieć status. To drobiazg tylko z pozoru. Status mówi, czy znaleziono e-mail, czy strona nie istnieje, czy nie udało się pobrać danych, czy firma nie ma strony WWW, czy rekord został pominięty jako duplikat.

Bez statusów system zmienia się w stertę wierszy. Z statusami staje się procesem. Można policzyć skuteczność, znaleźć problemy, ponowić tylko błędne przypadki i nie mieszać firm bez strony z firmami, których strona chwilowo nie odpowiedziała.

To samo dotyczy wysyłki. Status „sent” albo historia kampanii to hamulec bezpieczeństwa. Dzięki niemu system wie, że do danego kontaktu już wysłano wiadomość i nie powinien robić powtórki tylko dlatego, że ktoś ponownie uruchomił kampanię.

Sprawdzanie stron WWW musi mieć ograniczenia. Sensowne są timeouty, limity liczby odwiedzanych podstron, unikanie logowania, respektowanie publicznych zasad strony i skupienie na miejscach, gdzie kontakt faktycznie bywa publikowany: stopka, kontakt, o firmie, czasem podstrony serwisowe.

Celem nie jest przeczesanie całego internetu. Celem jest znalezienie jawnie opublikowanego kontaktu firmowego przy akceptowalnym koszcie i z minimalnym obciążeniem cudzych stron.

• Logować się na cudze strony, omijać zabezpieczeń ani pobierać danych z panelów niedostępnych publicznie.
• Automatycznie wysyłać wiadomości do wszystkiego, co wygląda jak adres e-mail.
• Ukrywać źródła danych. Jeśli nie wiadomo, skąd pochodzi kontakt, trudno mówić o kontroli procesu.
• Traktować konfiguracji jako dodatku. Sekrety, logi, limity i historia są częścią produktu, nie tłem technicznym.

Takie podejście ma sens dla małych firm i zespołów, które chcą uporządkować research rynku, znaleźć potencjalne firmy z określonej branży i przygotować kontrolowany pierwszy kontakt.

Szczególnie wtedy, gdy celem nie jest masowa wysyłka, tylko selektywny proces: znaleźć, sprawdzić, zapisać, odfiltrować, przejrzeć i dopiero wtedy wysłać wiadomość.

Nie jest to dobre narzędzie dla kogoś, kto chce nacisnąć przycisk i wysłać tysiące wiadomości bez kontroli. Taki kierunek zwykle szybko kończy się problemami z jakością danych, reputacją domeny i zwykłym ludzkim zmęczeniem odbiorców.

Prototyp pokazał, że ostrożna automatyzacja potrafi dać realny efekt. W badanej próbie około 63% firm posiadających stronę WWW miało możliwy do zapisania adres e-mail. To dobry wynik, zwłaszcza że proces opierał się na oficjalnym API i publicznych stronach, a nie na agresywnym scrapowaniu.

Jednocześnie ten sam prototyp pokazał, gdzie naprawdę leżą trudności: w jakości danych, deduplikacji, statusach, limitach wysyłki, konfiguracji Google Cloud, Gmail API, kontach usługowych, plikach sekretów i odpowiedzialnym rozdzieleniu wyszukiwania od mailingu.

Wniosek jest mniej efektowny niż obietnica „automatu do leadów”, ale znacznie bardziej użyteczny: dobra automatyzacja nie polega na tym, że system robi wszystko sam. Dobra automatyzacja robi powtarzalną część pracy, zapisuje ślady, pilnuje ograniczeń i zostawia człowiekowi decyzje tam, gdzie decyzje nadal mają znaczenie.