이메일 모듈을 유용한 카테고리로 구성하는 7가지 방법

게시 됨: 2021-05-17

따라서 이메일 모듈 또는 구성 요소를 사용하여 이메일을 작성하고 있으므로 상당한 시간을 절약할 수 있습니다. 그러나 지금 당신은 새로운 문제에 봉착하고 있습니다. 코드 모듈의 수가 증가함에 따라 쉽게 참조할 수 있도록 구성하는 방법은 무엇입니까? 다른 팀 구성원이 사용할 수 있도록 이러한 모듈을 어떻게 전달합니까? 그리고 그들이 올바른 것을 사용하는지 확인합니까?

이메일 제작 프로세스를 원활하게 실행하려면 이메일 모듈을 구성하는 방법이 있어야 합니다…

Litmus의 최신 기능인 디자인 라이브러리 카테고리를 소개하는 동안 제가 모자를 쓰고 있다고 상상해 보세요.

디자인 라이브러리를 사용하면 팀 전체의 빠른 공동 작업을 위해 주요 이메일 구성 요소를 한 곳에서 원활하게 생성, QA 테스트 및 저장할 수 있습니다. 이제 Litmus Enterprise 고객은 태그를 사용하여 스니펫 및 부분을 포함하여 디자인 라이브러리의 모듈을 분류하고 구성할 수 있습니다. 모듈은 유연한 사용 용이성을 위해 여러 범주에 속할 수도 있습니다.

리트머스 로고

Litmus Enterprise로 이메일 마케팅을 한 단계 업그레이드하십시오.

빠른 드래그 앤 드롭으로 이메일을 만들고, QA 테스트를 자동화하고, 검토 및 승인을 수집하고, 한 곳에서 고급 분석을 받으세요. 또한 원활한 워크플로를 위해 널리 사용되는 ESP와 통합합니다.

관심있는? 채팅하자 →

모듈 분류를 위한 아이디어

그렇다면 최고의 효율성을 위해 이메일 코드 모듈을 어떻게 구성해야 할까요? 폴더가 있는 플랫폼을 사용해 본 적이 있다면 이것이 말처럼 간단하지 않다는 것을 알 것입니다.

Marketing > Emails > Newsletters > Week of 5/17에서 이번 주 뉴스레터를 찾으시겠습니까? 또는 마케팅 > 이메일 팀 > 2021년 2분기 > 복사?

한 폴더에서 이메일을 찾을 것으로 예상할 수 있지만 팀의 다른 사람은 다른 위치에서 찾을 수 있습니다.

디자인 라이브러리에서 코드 모듈을 구성할 때 좋은 점은 태그 를 사용할 수 있다는 것 입니다. 이를 통해 모듈을 여러 위치에 "저장"할 수 있습니다. 따라서 "헤더"를 검색하든 "뉴스레터"를 검색하든 뉴스레터 헤더를 찾을 수 있습니다!

저는 최근에 이메일 팀과 함께 가장 좋아하는 코드 구성 방법을 배웠습니다. 다음은 내가 제안한 몇 가지를 포함하여 그들이 공유한 내용입니다.

1. 모듈 종류별

이 접근 방식에서는 모듈을 무엇인지에 따라 분류합니다. 다음과 같이 보일 수 있습니다.

  • 헤더
  • 바닥글
  • 이모티콘
  • 헤드샷
  • 버튼

이메일이 매우 간단하고 거의 모든 모듈을 사용할 수 있는 유연성이 있는 경우에 유용합니다. 모듈이 어디로 가야 하는지도 쉽게 알 수 있습니다. 따라서 디자인 모형이 있는 경우 올바른 스니펫 또는 부분을 가져와 생동감 있게 전달할 위치를 정확히 알 수 있습니다. 실수로 머리글에 바닥글을 넣는 일이 없습니다.

2. 청중별

이 옵션을 사용하면 대상에 따라 코드 블록을 그룹화할 수 있습니다. 잠재 고객 대 고객에 대해 사용하는 특정 머리글과 바닥글이 있습니까? 내부적으로 이메일을 보내나요? 이해 관계자 이메일에 특정한 모듈이 있습니까? 쉽게 참조할 수 있도록 대상에 따라 모듈에 태그를 지정합니다.

우리는 개인화와 세분화에 대해 많이 이야기합니다. 각 청중은 고유하며 다른 그룹과 다르게 특정 이메일 요소에 참여할 수 있습니다. 청중별로 모듈을 구성하면 고성능 디자인을 쉽게 고수할 수 있습니다.

3. 이메일 유형별

사용 사례별로 모듈을 구성할 수도 있습니다. 이것은 정기적으로 보내는 이메일을 다른 사람에게 넘길 때 유용한 옵션입니다. 태그를 사용하면 "해당 이메일에 대해 태그가 지정되어 있으면 사용하세요. 그렇지 않다면 사용하지 마십시오.”

Litmus에서는 Litmus Weekly, Leading FWD 및 월간 뉴스레터를 위해 이 작업을 수행합니다. 코드가 모두 한 곳에 있다는 것을 알고 있기 때문에 각 이메일을 훨씬 더 빠르게 구축할 수 있습니다.

4. 고객 또는 클라이언트에 의해

대행사인 경우 클라이언트별로 코드를 구성할 수 있습니다. 이 아이디어를 공유해 주신 Blue North Strategies의 Edward Spethmann에게 감사드립니다! 한 클라이언트의 이메일 디자인을 다른 클라이언트의 이메일 디자인과 혼동하고 싶지는 않을 것입니다. 각 고객 전용 카테고리가 있으면 올바른 이메일을 작성하기 위해 액세스해야 하는 디자인 요소를 명확하게 알 수 있습니다.

5. 팀 또는 부서별

팀 또는 부서별로 스니펫과 부분을 구성하는 것은 분산된 이메일 팀에 특히 유용합니다. 모든 이메일을 브랜드와 일관성을 유지하고 렌더링 문제 없이 유지하는 동시에 다른 사람들이 팀의 요구 사항에 맞는 이메일을 작성할 수 있도록 합니다. 코더가 아니더라도 어떤 모듈을 사용해야 하는지 알 수 있습니다.

6. 언어 또는 지역별

다른 언어로 이메일을 보내는 경우 HTML이 설정된 언어에 특히 주의를 기울여야 합니다. 예를 들어, 영어로 설정된 HTML은 프랑스어 텍스트에서 제대로 작동하지 않습니다. 그리고 스크린 리더는 사본을 제대로 읽을 수 없습니다. 언어 또는 지역별로 분류하면 완벽한 읽기 경험을 위해 올바른 코드가 사용됩니다.

7. 이메일 서비스 제공자(ESP)

이전 아이디어와 유사하게 각 ESP는 태그 및 동적 콘텐츠를 개인화하거나 병합할 때 고유한 언어를 사용합니다. 따라서 둘 이상의 작업을 수행하는 경우 조심해야 합니다. 그렇지 않으면 매우 흔한 "Hello %%FirstName%%" 사고가 발생할 위험이 있습니다. 디자인 라이브러리에서 ESP 관련 카테고리를 만드는 것은 이러한 어색한 상황을 피하는 좋은 방법입니다.

코드 모듈 구성을 위한 3가지 기본 원칙

이것은 확실히 옵션의 완전한 목록이 아닙니다.

마케팅의 많은 일과 마찬가지로 코드를 구성하는 올바른 방법은 없습니다. 우리에게 효과가 있는 것이 귀하에게는 효과가 없을 수도 있습니다. 다음은 태그를 설정하는 데 도움이 되는 몇 가지 기본 원칙입니다.

기존 조직 시스템이 있는 경우 사용

여기서 바퀴를 재발명할 필요가 없습니다. 이미 작업을 조직화하는 방법이 있다면 그 방법을 고수하십시오. 클라우드 스토리지, 디자인 플랫폼 또는 ESP에 사용하는 시스템일 수 있습니다.

처음부터 시작하는 경우 모든 이해 관계자를 통합하십시오.

이메일 프로세스에 관련된 다양한 사람들로부터 통찰력을 수집하십시오. 제품 팀, 디자인 팀 및 마케팅 팀에서 사람들을 모으십시오. 이 코드를 참조하거나 사용할 수 있는 디자이너, 개발자 및 전략가를 포함합니다. 이 그룹에서 동의를 얻으면 조직 시스템이 기능할 뿐만 아니라 실제로 여러 팀에서 사용되도록 하는 데 도움이 됩니다.

목표를 최우선으로 하라

코드를 구성할 때 가장 중요한 것은 사람들이 코드를 찾을 수 있다는 것입니다. 이메일 워크플로 아래에 있는 사람들에 대해 생각해 보십시오. 다음에 귀하의 직업을 갖게 될 사람에 대해 생각해 보십시오. 코드를 어디에서 찾을 수 있을까요? 당신은 당신을 위해 조직 시스템을 구축하는 것뿐만 아니라 현재와 미래에 프로세스에 관련된 다른 사람들을 위해 조직 시스템을 구축하는 것입니다.

적합한 모듈을 쉽게 찾고 사용

우리의 아이디어를 사용하거나 귀하와 귀하의 팀에 가장 적합한 다른 구성 방법을 찾으십시오. 디자인 라이브러리의 카테고리가 도움이 될 수 있습니다. 우리는 당신이 코멘트에서 무엇을 하고 있는지 듣고 싶습니다.

현재 Litmus Enterprise 고객입니까? 시작하려면 디자인 라이브러리로 이동하십시오.

그렇지 않으면 저희에게 연락하여 Litmus로 정리를 유지할 수 있는 방법을 알아보십시오.