웹사이트 파생 로컬 비즈니스 이메일

대부분의 로컬 디렉토리는 웹사이트로 안내합니다. 이메일은 목록이 아닌 그 웹사이트에서 옵니다.

Yelp, Angi, BBB, Thumbtack 및 유사한 디렉토리는 비즈니스의 공개 존재감을 노출합니다. 이름, 카테고리, 전화번호, 주소 및 웹사이트 URL. 일반적으로 노출하지 않는 것은 이메일 주소입니다. 이메일은 한 단계 후에 찾아야 합니다. 목록이 링크하는 웹사이트를 방문하고 거기서 연락 주소를 찾아야 합니다.

이 두 단계 경로 — 디렉토리 목록에서 웹사이트로, 그리고 이메일로 — 는 대규모 대부분의 로컬 비즈니스 아웃리치를 위한 표준 검색 경로입니다. 생성하는 품질 위험은 이메일을 직접 목록하는 디렉토리에서 만든 목록과 다릅니다. 그 위험을 이해하고 발송 전에 인증을 실행하는 것이 배달 가능한 목록과 첫 번째 캠페인에서 발신자 평판을 손상시키는 목록을 구분합니다.

이메일을 직접 노출하는 디렉토리와 웹사이트 검색이 필요한 디렉토리.

모든 로컬 디렉토리가 같은 방식으로 작동하지는 않습니다. 일부는 대부분의 프로필에 이메일 주소를 목록합니다. 다른 것들은 거의 그렇게 하지 않습니다.

"드물게" 또는 "거의 없음" 열의 디렉토리의 경우, 결과 목록의 모든 이메일 주소가 웹사이트 파생입니다. 이것이 대규모 Yelp, Angi, Thumbtack, 또는 Bark 소싱 작업의 시작 가정입니다.

로컬 비즈니스 웹사이트에서 연락 이메일을 찾는 곳.

디렉토리 목록에서 비즈니스 웹사이트로 이동하면 연락 이메일 주소가 나타날 가능성이 높은 다섯 곳이 있습니다.

연락 페이지: 가장 일반적인 위치입니다. 대부분의 비즈니스 웹사이트에는 "연락", "문의하기", 또는 "연락하세요"라는 제목의 페이지가 있습니다. 이메일 주소는 일반 텍스트로 표시되거나 mailto: 앵커로 링크됩니다. 일부 연락 페이지는 이메일 주소가 보이지 않는 양식만 표시합니다. 그 경우는 아래에서 설명합니다.

푸터: 두 번째로 일반적인 위치입니다. 많은 소규모 비즈니스 웹사이트는 전화번호 및 주소와 함께 푸터에 연락 이메일을 배치합니다. 푸터 이메일은 모든 페이지에서 보이므로 자동 검색 중에 쉽게 찾을 수 있습니다.

소개 또는 팀 페이지: 이름이 있는 직원이 있는 비즈니스는 소개 또는 팀 페이지에 개별 이메일 주소를 나열하는 경우가 있습니다. 공유 받은편지함이 아닌 특정 사람과 연결되어 있어 가장 가치 있는 연락처인 경우가 많습니다.

예약 또는 스케줄링 페이지: 서비스 비즈니스 (살롱, 계약업체, 컨설턴트)는 때때로 온라인 양식 사용을 선호하지 않는 고객을 위한 대안으로 예약 또는 스케줄링 페이지에 이메일 주소를 배치합니다.

Google 비즈니스 프로필 링크: 비즈니스의 Google 비즈니스 프로필에 소유자가 입력한 이메일 주소가 표시될 수 있습니다. 이것이 항상 웹사이트에 표시되는 것과 같지는 않지만, 웹사이트에서 아무것도 나오지 않을 때 유용한 보조 확인입니다.

웹사이트 파생 이메일에 특정한 품질 위험.

웹사이트 파생 이메일은 디렉토리 목록 이메일의 위험과 다른 품질 문제를 도입합니다. 디렉토리 목록 이메일은 대개 오래되어 있습니다. 웹사이트 파생 이메일은 다른 방식으로 오래될 수 있으며, 디렉토리 경로에는 없는 새로운 위험을 추가합니다.

오래된 연락 페이지: 소규모 비즈니스 웹사이트는 수년간 업데이트되지 않았을 수 있습니다. 연락 페이지의 이메일 주소는 떠난 직원, 비즈니스가 더 이상 사용하지 않는 도메인, 또는 아무도 확인하지 않는 받은편지함에 속할 수 있습니다. 웹사이트는 여전히 접근 가능하기 때문에 활성처럼 보이지만 이메일은 죽어 있습니다. 인증은 하드 반송을 잡습니다. 하지만 모니터링되지 않는 받은편지함으로 라우팅되는 주소는 반송되지 않습니다. 그냥 응답이 없을 것입니다.

소유자 이메일 대신 웹마스터 또는 개발자 이메일: 웹 디자인 에이전시나 프리랜서를 사용하여 사이트를 만든 비즈니스는 때때로 에이전시 이메일 또는 개발자가 푸터나 연락 페이지에 만든 일반 주소를 갖게 됩니다. 이 주소는 비즈니스 자체의 누구에게도 라우팅되지 않을 수 있습니다. 인증의 신호는 유효일 수 있습니다. 사서함이 존재합니다. 하지만 연락처는 아웃리치에 쓸모가 없습니다.

Catch-all 도메인: 많은 소규모 비즈니스는 도메인의 catch-all 수신을 기본으로 하는 공유 호스팅 제공업체를 사용합니다. 그 도메인의 모든 주소로 보내는 모든 이메일이 수락됩니다. 이는 SMTP 인증 확인이 특정 사서함이 존재하지 않더라도 주소를 배달 가능으로 보고함을 의미합니다. 소규모 비즈니스 도메인의 웹사이트 파생 이메일은 더 구조화된 이메일 인프라를 가진 비즈니스보다 더 높은 catch-all 비율을 가집니다.

이메일을 숨기는 연락 양식: 상당 비율의 소규모 비즈니스 웹사이트가 보이는 이메일 주소를 연락 양식으로 대체했습니다. 이는 의도적입니다. 비즈니스가 스팸을 줄이기 위해 이렇게 합니다. 검색 관점에서, 이는 페이지에서 추출할 이메일 주소가 없음을 의미합니다. 비즈니스에는 도메인, 작동하는 웹사이트, 연락 경로가 있습니다. 하지만 이메일 주소 자체는 보이지 않습니다.

깨지거나 오래된 디렉토리 링크의 잘못된 도메인: 디렉토리 목록은 이동하거나 판매되거나 교체된 웹사이트에 링크될 수 있습니다. 링크된 사이트를 방문하여 거기서 연락 이메일을 찾으면, 그 이메일은 현재 그 도메인을 소유한 누구에게든 속합니다. 이는 디렉토리에서 찾은 비즈니스가 아닐 수 있습니다. 특히 오래된 Yellow Pages 또는 BBB 목록에서 드물지만 실제 실패 모드입니다.

단계별 검색 및 인증 워크플로.

1. 디렉토리 목록 수집
   → 비즈니스 이름, 전화번호, 주소, 카테고리, 웹사이트 URL 수집
   → 직접 목록된 이메일이 있는 목록 확인
   → 웹사이트 URL이 없는 목록 확인 (이메일 검색 불가)

2. 각 비즈니스 웹사이트 방문
   → 확인: 연락 페이지, 푸터, 소개/팀 페이지, 예약 페이지
   → 보이는 이메일 주소 추출
   → 연락 양식만 있는 경우: 양식 전용으로 표시, 이메일 검색 불가
   → 웹사이트가 깨지거나 접근 불가한 경우: 죽은 링크로 표시, 이메일 검색 불가

3. 보이는 이메일이 없는 도메인에 이메일 검색기 실행 (선택 사항)
   → 검색기 도구를 사용하여 도메인에 대한 가능한 주소 생성 또는 검색
   → 검색기 결과와 직접 검색된 이메일 결합
   → 검색기 생성 주소는 별도로 표시 — 더 많은 불확실성 포함

4. 수집된 목록 정규화
   → 모든 주소 소문자로
   → 앞뒤 공백 제거
   → 잘못된 항목 제거 (@없음, 불완전한 도메인)
   → 이메일 주소별 중복 제거
   → 여러 주소가 같은 비즈니스를 가리키는 경우 도메인별 중복 제거

5. 억제 검사
   → 인증 실행 전에 기존 억제 파일과 비교
   → 억제에 나타나는 주소 제거

6. BillionVerify로 인증
   → 정규화된 억제 검사된 목록 업로드
   → BillionVerify가 각 주소의 구문, 도메인 유효성, MX 레코드 및 SMTP 응답 확인

7. 신호별 결과 라우팅
   → 아래 라우팅 표 참조

8. 승인된 세그먼트 가져오기
   → 메인 캠페인: 유효, 비역할 기반
   → 공유 받은편지함 캠페인: 유효 역할 기반
   → 신중한 저용량 세그먼트: Catch-all
   → 가져오지 않음: 유효하지 않음, 위험, 일회용
   → 검토 대기열: 알 수 없음

웹사이트 파생 이메일의 BillionVerify 결과 라우팅.

Catch-all 결과는 웹사이트 파생 로컬 비즈니스 목록에서 일반적입니다. 많은 소규모 비즈니스가 기본적으로 도메인의 모든 메일을 수락하는 공유 호스팅 플랜에서 운영합니다. 목록의 catch-all 비율이 높다면, 소규모 배치를 먼저 테스트하고 24-48시간 동안 반송 및 불만 비율을 확인하지 않고 전체 catch-all 세그먼트에 발송하지 마세요.

역할 기반 결과도 일반적입니다. 대부분의 소규모 비즈니스 연락 페이지는 이름 있는 개인이 아닌 일반 info@ 또는 contact@ 주소를 노출합니다. 이것들은 실제 배달 가능한 받은편지함입니다. 하지만 그날 공유 받은편지함을 확인하는 누구에게든 라우팅됩니다. 이러한 주소에 대한 아웃리치 메시지는 특정 독자를 가정해서는 안 됩니다.

웹사이트 파생 로컬 이메일 자주 묻는 질문.

웹사이트 이메일이 디렉토리 목록 이메일보다 더 신뢰할 수 있나요?

반드시 그렇지는 않습니다. 신뢰성은 이메일이 웹사이트에서 왔는지 디렉토리 목록에서 왔는지가 아닌 웹사이트가 얼마나 최근에 업데이트되었는지에 따라 달라집니다. 비즈니스 소유자가 정기적으로 업데이트하는 디렉토리 목록 이메일은 3년 동안 수정되지 않은 웹사이트 연락 페이지보다 더 최신일 수 있습니다. 웹사이트 파생 이메일은 안정적이지만 비개인적인 역할 기반 일반 받은편지함이 되는 경향이 있습니다. 디렉토리 목록 이메일은 존재할 때 소유자의 직접 주소인 경우가 있어 더 가치 있지만 변경될 가능성도 더 높습니다. 두 경우 모두 인증이 발송 전에 배달 가능성을 확인하는 유일한 신뢰할 수 있는 방법입니다.

연락 양식만 있는 비즈니스에서 이메일을 어떻게 찾나요?

비즈니스 웹사이트에 보이는 이메일 주소 없이 연락 양식만 있다면 두 가지 옵션이 있습니다. 첫 번째는 비즈니스 도메인에 이메일 검색기 도구를 실행하는 것입니다. 검색기는 페이지에 보이는 이메일 없이도 메일 서버 프로빙 및 패턴 매칭을 사용하여 가능한 주소를 발견하거나 추론합니다. 검색기의 결과는 직접 스크랩된 주소보다 더 많은 불확실성을 가지므로 낮은 신뢰도 세그먼트로 취급해야 합니다. 두 번째 옵션은 이 비즈니스가 이 경로로 이메일로 도달할 수 없음을 수락하고 대신 전화 아웃리치를 위해 기록하는 것입니다. 대규모 아웃리치의 경우, 모든 디렉토리 소싱 목록의 일부 비즈니스는 검색 가능한 이메일이 없습니다. 이것은 예상됩니다.

웹사이트가 깨지거나 도메인이 만료된 경우 어떻게 하나요?

깨지거나 접근 불가한 웹사이트는 이메일을 추출할 수 없음을 의미합니다. 도메인도 만료된 경우, 그 도메인에 대해 가지고 있는 모든 이메일 주소는 하드 반송을 생성합니다. MX 레코드가 없거나 도메인이 더 이상 확인되지 않기 때문에 BillionVerify는 유효하지 않은 결과를 반환합니다. 이러한 비즈니스는 이메일 아웃리치에서 제외하고 억제에 추가해야 합니다. 확인되지 않는 도메인은 때때로 비즈니스가 폐업하거나 이전했음을 나타낼 수 있습니다. 그 경우, 이메일로는 의미 있는 연락 경로가 없습니다.

웹사이트를 새 도메인으로 이동한 비즈니스를 어떻게 처리하나요?

디렉토리 목록이 새 도메인으로 리디렉션되는 이전 도메인에 링크되어 있다면, 이메일 검색에 새 도메인을 사용하세요. 리디렉션된 사이트를 방문하고, 연락 이메일을 찾고, 현재 도메인에 대해 인증하세요. 이전 도메인으로 형식화된 이메일 주소는 사용하지 마세요. 그 주소들은 반송되거나 비즈니스가 더 이상 제어하지 않는 도메인으로 라우팅될 가능성이 높습니다. 이전에 이전 도메인의 주소를 수집했다면, 유효하지 않은 것으로 취급하고 현재 도메인에서 다시 검색하세요.

직접 검색된 주소와 검색기 생성 주소를 별도로 인증해야 하나요?

네. 웹사이트 연락 페이지 또는 푸터에서 직접 추출한 주소는 검색기 도구로 생성된 주소보다 위험이 낮습니다. 검색기 생성 주소는 교육된 추측입니다. 도메인이 유효하고 메일 서버가 응답하더라도 실제 사서함에 해당하지 않을 수 있습니다. BillionVerify 업로드에서 이 두 그룹을 별도로 유지하면 결과를 라우팅할 때 다른 위험 임계값을 적용하기 쉬워집니다. 모든 유효한 직접 검색 주소를 가져오면서 어떤 유효한 검색기 생성 주소를 발송할지 더 선택적으로 결정할 수 있습니다.

캠페인에 들어가기 전에 모든 웹사이트 파생 이메일을 인증하세요.

디렉토리 목록에서 웹사이트로, 그리고 이메일로의 두 단계 경로는 모든 단계에서 품질 불확실성을 추가합니다. 웹사이트가 오래되었을 수 있습니다. 이메일이 잘못된 사람에게 속할 수 있습니다. 도메인은 특정 사서함이 존재하지 않더라도 모든 메일을 수락할 수 있습니다. 이러한 문제들은 인증 없이는 보이지 않습니다.

발송 전에 모든 웹사이트 파생 로컬 비즈니스 이메일을 BillionVerify를 통해 실행하세요. 신호별로 라우팅하세요. 조정된 볼륨과 메시지로 catch-all 및 역할 기반 주소를 별도 세그먼트에 유지하세요. 모든 유효하지 않은 주소를 즉시 억제에 추가하여 동일한 디렉토리에서 소싱된 미래 목록에 같은 죽은 주소가 나타나지 않도록 하세요.