ELAN Tier Structure Template (Speakers, Translation, Notes, Codes) + Examples

An ELAN tier structure template is a consistent set of tiers (speaker, translation, notes, and analytic codes) that you reuse across files so your team can search, compare, and analyze data without rework. A good template keeps speaker transcription separate from translation, separates “what was said” from “your interpretation,” and uses the same tier names in every session. Below is a practical tier plan with examples for single-speaker interviews and multi-party interaction.

Primary keyword: ELAN tier structure template.

Key takeaways

• Use one speaker transcription tier per participant, plus linked child tiers for translation, notes, and codes.
• Keep translation and analysis on separate tiers so you can filter and export cleanly.
• Adopt a team naming convention (prefixes, speaker IDs, case rules) and enforce it in every file.
• Start simple: a small, stable tier set beats a large, changing one.

What a “good” ELAN tier structure looks like

Most ELAN projects work best when tiers follow four layers: (1) who is speaking, (2) what they said, (3) what it means in another language, and (4) what you, the analyst, add as notes or codes. This layout makes exports predictable and helps multiple coders work without stepping on each other.

In ELAN terms, you usually create a top-level Alignable tier for each speaker’s transcription, then create Referring tiers for translation, notes, and codes that point to those transcription annotations. That way, translation and codes inherit the time boundaries of the original speech.

Core design rules (use these as your template principles)

• One job per tier: transcription tiers contain only words spoken, not translations or interpretations.
• Stable speaker IDs: assign each person a short ID and keep it across sessions (e.g., P01, INT, TCH).
• Parallel structure: every speaker tier has the same child tiers, even if some remain empty.
• Make uncertainty explicit: use consistent conventions (e.g., (unclear), [overlap], ? markers) rather than “fixing” audio silently.
• Separate observation from analysis: descriptive notes (what happens) and analytic codes (your categories) should not mix.

Recommended tier structures for typical studies

Below are tier sets that work for many common ELAN use cases, including interviews, conversation analysis, and multilingual fieldwork. You can copy these into a shared “template” .eaf and duplicate it for each new recording.

Tier group 1: Speaker transcription tiers (the backbone)

Create one top-level transcription tier per speaker. Keep the tier name short and consistent, and use it as the parent for translation, notes, and codes.

• spk_INT (Interviewer transcription)
• spk_P01 (Participant 1 transcription)
• spk_P02 (Participant 2 transcription)

Recommended linguistic type: Alignable (time-align to the media). If you plan a second segmentation level (like words), use a child tier for that rather than breaking your main transcription too small.

Tier group 2: Translation tiers (linked to each speaker)

Create translation tiers as children of each speaker’s transcription tier. This keeps translation aligned and makes bilingual exports easy.

• tr_en_INT (English translation of spk_INT)
• tr_en_P01 (English translation of spk_P01)
• tr_es_P01 (Spanish translation if needed)

Tip: Put the target language in the tier name (e.g., tr_en, tr_fr) so you can add more languages later without confusion.

Tier group 3: Notes tiers (what happened + workflow notes)

Notes help later analysis and quality control, but only if you separate “event descriptions” from “editorial workflow notes.” Consider two note types per speaker plus optional global notes.

• note_event_P01 (what happens: laughter, pointing, phone rings)
• note_qc_P01 (quality checks: unclear segment, speaker ID doubt)
• note_global (session-level notes: setting, participants, recording issues)

Recommended content rules: keep notes short; start with a tag like “ENV:”, “UNCLEAR:”, “NONVERBAL:”, or “TECH:” for quick scanning.

Tier group 4: Analytic code tiers (categories, not commentary)

Analytic tiers hold your codes, labels, or tags used for later sorting and counts. Keep a separate tier for each code family only if your scheme is large; otherwise, use one code tier and a controlled vocabulary.

• code_theme_P01 (topic/theme codes)
• code_action_P01 (speech act or action type)
• code_ca_P01 (conversation analysis features: overlap, repair, turn type)

Best practice: agree on a codebook and spelling before coding. If your team codes in parallel, require coders to use the same tag set (e.g., THEME:trust, ACT:request).

Examples: single-speaker interview vs multi-party interaction

These examples show complete, ready-to-use tier sets. Adjust the speaker IDs and translation languages to match your project.

Example A: Single-speaker interview (interviewer + one participant)

This setup fits oral history, user research, clinical interviews, and most one-on-one qualitative studies.

• spk_INT
  • tr_en_INT
  • note_event_INT
  • note_qc_INT
  • code_theme_INT
  • code_action_INT
• spk_P01
  • tr_en_P01
  • note_event_P01
  • note_qc_P01
  • code_theme_P01
  • code_action_P01
• note_global

When to add more tiers: add a code_sensitive_P01 tier if you flag personal data, or a note_consent tier if you track consent events (start/stop recording).

Example B: Multi-party interaction (3–6 speakers, overlap, fast turns)

This setup fits classroom talk, meetings, focus groups, and natural conversation where overlap matters.

• spk_P01
  • tr_en_P01
  • note_event_P01
  • note_qc_P01
  • code_ca_P01
  • code_theme_P01
• spk_P02
  • tr_en_P02
  • note_event_P02
  • note_qc_P02
  • code_ca_P02
  • code_theme_P02
• spk_P03
  • tr_en_P03
  • note_event_P03
  • note_qc_P03
  • code_ca_P03
  • code_theme_P03
• note_global

If overlap is central: keep transcription chunks short (one turn construction unit, if that fits your method), and use the notes tier to flag overlap points consistently (e.g., “OVL starts”). If you need fine-grained overlap marking, add a dedicated tier like note_overlap_P01 rather than mixing overlap notes into general events.

Team naming rules that prevent chaos

Tier names become your dataset’s column headers, so small inconsistencies cause big problems during merges and exports. Agree on a naming guide before anyone creates tiers.

1) Use a simple prefix system

• spk_ = original-language transcription (what was said)
• tr_ = translation (target language included)
• note_ = descriptive or workflow notes
• code_ = analytic codes (your categories)

2) Standardize speaker IDs

• Pick one style: P01 not P1, and stick with it.
• Use role-based IDs where it helps: INT (interviewer), TCH (teacher), MOD (moderator).
• Avoid real names in tier labels if files leave your team.

3) Choose one case style and keep it

• Use lowercase prefixes (spk_, tr_, note_, code_) and uppercase IDs (P01, INT) for readability.
• Avoid spaces and special characters; underscores make exports safer.

4) Decide how you will name translation languages

Use a short, consistent language tag. If your project uses ISO language codes, apply them everywhere (e.g., en, es, fr), and keep the tag in the same position: tr_en_P01.

5) Lock a template and duplicate it

Create one “gold” .eaf with all tiers and linguistic types, then duplicate it for each session. This practice reduces the chance that one file has tr_EN_P01 while another has translation_P01.

Practical setup steps in ELAN (and common pitfalls)

You can build the template in under an hour if you decide the naming rules first. Use these steps as a checklist.

Step-by-step checklist

• List participants and assign stable IDs (P01, P02, INT).
• Create one alignable tier per speaker (spk_P01, spk_INT).
• Create child tiers for translation, notes, and codes that refer to the speaker tier.
• Set controlled vocabularies for codes (optional but helpful for team consistency).
• Save as a template file and duplicate for each recording.
• Write a one-page tier guide that states what goes where, with 2–3 examples.

Pitfalls to avoid

• Mixing translation into the transcription tier: it makes exports messy and hides what language the words came from.
• Changing tier names mid-project: it breaks batch analysis and forces manual cleanup.
• Over-building tiers: too many tiers slow annotation and confuse new coders.
• Using notes as codes: notes drift in wording; codes should come from a defined tag set.
• Inconsistent segmentation: decide whether annotations represent turns, clauses, or sentences, then keep it consistent.

Common questions

Do I need separate tiers for every translation language?

Yes, if you plan to store more than one target language. Separate tiers like tr_en_P01 and tr_es_P01 prevent confusion and make it easy to export only the language you need.

Should translation tiers be children of speaker tiers or independent?

Make them children when you want translation to match the same time span as the original speech. Use independent translation tiers only if your translation will not line up one-to-one with the transcription segments.

How do we handle overlapping speech in multi-party data?

Keep a separate speaker tier for each participant and let time ranges overlap naturally. Use a dedicated overlap note convention (or tier) so everyone marks overlap the same way.

What is the difference between notes and analytic codes?

Notes describe what you observe or what needs attention (e.g., “laughter,” “unclear audio”). Analytic codes label data with your study categories (e.g., “complaint,” “repair,” “trust”).

How many code tiers should we create?

Start with one code tier per speaker (e.g., code_theme_P01) and add more only if you truly have separate code families. Too many code tiers can slow coding and create duplicates.

What if our team needs both verbatim and cleaned transcripts?

Keep verbatim on the main speaker tier and put “cleaned” text on a dedicated child tier (e.g., spkClean_P01) so you never lose the original wording. Document what “cleaned” means in your tier guide.

How can we keep tier names consistent across dozens of files?

Use a single template .eaf, duplicate it for each session, and forbid “ad hoc” tier creation without updating the template. A short tier naming cheat sheet in your project folder also helps new team members.

When you may want transcription or translation support

ELAN projects often stall when teams spend too much time getting from audio to analyzable text. If you already have recordings and need clean transcripts, timestamps, or translations that you can then import and annotate, GoTranscript offers professional transcription services that can support your workflow without changing your tier structure.