Clay opisuje proces, w którym cztery tabele pobierają treść wskazanej strony firmy, zachowują kolejne odczyty i porównują dwa najnowsze. Jeśli porównanie wskaże nową informację, możesz zapisać ją w kolejce do ręcznej oceny. Przed przekazaniem rekordu handlowcowi sprawdź adres strony i samą zmianę: nowy tekst na stronie nie dowodzi, że firma planuje zakup.
Poniższa procedura opiera się na oficjalnej dokumentacji Clay, sprawdzonej 25 września 2026 r. Nie była uruchamiana na koncie Clay. Przykłady pokazują oczekiwane zachowanie, które trzeba sprawdzić podczas własnej próby.
Przygotuj adresy i pola
Zacznij od listy firm. Dla każdej zapisz nazwę, domenę i dokładny URL strony, którą chcesz obserwować. W tym procesie przypisz jeden obserwowany URL do jednej domeny. Tabela historii będzie później wyszukiwana po domenie, więc porównanie odczytów z różnych podstron dałoby mylący wynik.
Potrzebujesz konta Clay z dostępem do pobierania treści strony, akcji Use AI i harmonogramu ponawiania tabel. Wynikiem procesu ma być rekord z nazwą firmy, domeną, adresem strony, opisem nowej informacji i czasem utworzenia rekordu. Dodaj też pole na ręczną decyzję o przekazaniu go handlowcowi.
Ustaw cztery tabele w Clay
1. Tabela źródłowa: pobierz stronę
W tabeli źródłowej umieść listę firm i ich adresy. Do pobrania treści możesz użyć akcji Run Zenrows scrape, która przyjmuje URL strony jako dane wejściowe. Opisuje ją dokumentacja integracji Zenrows w Clay.
Włącz Re-run columns on a schedule. Clay podaje, że nie wybierzesz dokładnej godziny kolejnego uruchomienia: harmonogram wykonuje się co 24 godziny od jego włączenia.
Skonfiguruj Actions → Send table data, aby po odczycie przesłać domenę, URL i pobraną treść do tabeli Run history. Wyłącz Update existing rows on re-run, tak aby kolejny odczyt dodał wiersz zamiast zastąpić poprzedni.
2. Run history: zachowaj kolejne odczyty
W tabeli Run history każdy odczyt powinien mieć osobny wiersz. Odkryj kolumnę Created At. Pokazuje ona, kiedy Clay utworzył rekord, a nie kiedy firma zmieniła stronę.
Przed porównaniem sprawdź, czy wiersze przypisane do danej domeny mają ten sam URL. Jeśli adresy są różne, nie traktuj ich jako dwóch wersji tej samej strony.
3. Lookup: porównaj dwa najnowsze odczyty
W tabeli Lookup użyj Actions → Lookup Multiple Rows in Other Table i wyszukaj historię po domenie. Wybierz dwa najnowsze odczyty według Created At. Ponownie sprawdź zgodność URL-i, zanim ocenisz różnicę w treści.
Zaplanuj uruchomienie Lookup z odstępem względem pobierania strony. Dokumentacja Clay zaleca odstęp między pracą tych tabel, ale nie podaje tu gwarantowanego czasu przepływu danych.
Dla tekstu opisowego możesz użyć Actions → Use AI. Poniższy prompt jest propozycją do dostosowania do kolumn w Twojej tabeli. Nazwy pól wyniku również ustalasz na potrzeby tej konfiguracji.
Porównaj dwa odczyty tej samej strony.
Starszy odczyt: {{older_content}}
Nowszy odczyt: {{newer_content}}
W polu change_description opisz jednym zdaniem informację, która pojawiła się
w nowszym odczycie. Jeśli nie ma nowej informacji, pozostaw pole puste.
W polu change_detected zwróć True, gdy pojawiła się nowa informacja.
Zwróć False, gdy treść jest taka sama lub różni się tylko formatowaniem.Prompt nie zastępuje kontroli adresu strony. Sprawdź też w odpowiedzi Use AI, czy opis dotyczy obserwowanego fragmentu, a nie przypadkowej zmiany w pozostałej części strony.
4. Signal: zapisz rekord do oceny
W tabeli Lookup skonfiguruj Actions → Send table data do tabeli Signal z warunkiem `change_detected = True`. Do rekordu przekaż nazwę firmy, domenę, URL i opis nowej informacji. Created At rekordu Signal traktuj jako czas jego utworzenia w Clay, nie jako datę zmiany strony przez firmę.
Dodaj pole ręcznej decyzji: „przekazać handlowcowi” albo „nie przekazywać”. Samo utworzenie rekordu nie powinno wysyłać wiadomości do firmy.
Sprawdź proces na fikcyjnych danych
Te trzy scenariusze służą do zaplanowania próby. Podane wyniki są oczekiwane, a nie zaobserwowane w Clay.
1. Dla `https://example.com/technologie` starszy odczyt brzmi „Integracje: CRM”, a nowszy „Integracje: CRM i ERP”. Oczekujesz opisu dodania ERP, wyniku `True` i nowego rekordu Signal.
2. Osobnym przykładem jest `https://example.com/dostawcy`: tekst „Wymagania wobec dostawców: formularz kontaktowy” zmienia się na „Wymagania wobec dostawców: formularz kontaktowy i ankieta bezpieczeństwa”. To alternatywna próba, a nie drugi URL monitorowany równolegle dla domeny `example.com`. Nie mieszaj jej odczytów z pierwszym przykładem.
3. Dwa kolejne odczyty tekstu „Integracje: CRM i ERP” nie zawierają zmiany. Oczekujesz `False` i braku nowego rekordu Signal.
Przy własnej próbie zapisz:
- URL oraz czasy obu odczytów z Created At;
- treść przed zmianą i po niej;
- opis różnicy oraz wynik Use AI;
- liczbę rekordów Signal przed próbą i po niej;
- zużycie przed próbą i po niej w Settings → Usage oraz widoku właściwej tabeli;
- wynik ręcznego sprawdzenia strony i decyzję o przekazaniu rekordu handlowcowi.
Dokumentacja zużycia Clay opisuje, gdzie odczytać dane według tabeli i uruchomienia. Bez próby na własnym koncie nie da się podać kosztu tego procesu ani potwierdzić, że Use AI zwróci oczekiwane wyniki.
Kiedy przekazać rekord handlowcowi
Otwórz URL zapisany w rekordzie i sprawdź, czy nowa informacja nadal jest na stronie oraz czy dotyczy firmy, którą obserwujesz. Dopiero wtedy oceń, czy handlowiec ma powód, by się nią zainteresować. Dopisek o ERP może oznaczać zmianę opisu integracji; sam w sobie nie potwierdza wdrożenia ani zamiaru zakupu.
Jeśli strona nie daje się pobrać, odczyt nie obejmuje potrzebnego fragmentu albo dwa rekordy mają różne URL-e, nie przekazuj wyniku jako potwierdzonego sygnału. Najpierw popraw dane wejściowe lub konfigurację i powtórz kontrolę.
Źródła
- Clay, Custom Signals — cztery tabele, harmonogram, porównanie odczytów i warunkowy zapis rekordu.
- Clay, Zenrows Integration Overview — pobieranie danych strony na podstawie URL-a.
- Clay, Credit Usage — widoki zużycia w Clay.
