Data Export 

Overview

After conducting interviews using Interviewer or Fresco, you need to export the data for analysis. Network Canvas provides flexible export options that allow you to export data in formats compatible with statistical software, network analysis programs, and spreadsheet applications.

The export process transforms your interview data—including ego attributes, alter attributes, and edge data—into structured files that you can import into analysis tools such as R, Python, SPSS, UCINET, Gephi, and many others.

Where to export from

This page describes what Network Canvas exports contain, regardless of which application produced them. The steps for actually running an export differ by application — Interviewer and Interviewer Classic store data on the device and export it as files you keep, while Fresco stores data centrally and exports from its dashboard. Each application's own guide walks through its export workflow:

• Interviewer — see Using Interviewer
• Interviewer Classic — see Interviewer Online and Offline Workflows
• Fresco — see Using Fresco

Some details on this page apply only to exports from Interviewer and Fresco: how files and GraphML attributes are named, and the warnings shown when characters are removed or columns are renamed. Interviewer Classic uses an earlier version of the export code, and runs only schema 7 protocols, whose names are more limited.

File types

Network Canvas supports two file formats for data export. Choose the format that best suits your analysis needs.

CSV format

What it is: Comma-Separated Values (CSV) files are plain text files that represent tabular data. The CSV export creates multiple files, one for each type of entity in your network data, and complies with the egor package standard.

Best for:

• Statistical analysis in R, Python, SPSS, Stata, SAS
• Spreadsheet applications (Excel, Google Sheets, LibreOffice Calc)
• The egor package in R
• Custom data processing workflows

What you get:

The CSV export creates separate files for each entity type in your protocol:

Ego attribute list

• One row for the interview's ego (participant)
• Filename format: caseID_sessionUUID_ego.csv (see How export files are named)
• Contains:
  • Ego-level variables you collected
  • Session metadata (start time, finish time, protocol name, etc.)
  • How the interview ended (see How the interview ended)
  • Network Canvas identifiers (ego UUID, case ID, session ID)

Example structure:

networkCanvasEgoUUID,networkCanvasCaseID,networkCanvasSessionID,networkCanvasProtocolName,sessionStart,sessionFinish,sessionExported,APP_VERSION,COMMIT_HASH,networkCanvasFinishOutcome,age,gender_female,gender_male,gender_non_binary
abc123,case_001,sess456,My Study,2025-01-15T10:30:00.000Z,2025-01-15T11:15:00.000Z,2025-01-16T09:00:00.000Z,9.0.0,1a2b3c4,completed,34,false,true,false

The identifier and session columns always come first, in this order, followed by your ego variables. A categorical variable such as gender becomes one true/false column per option (see the Export Data Dictionary).

Alter attribute list

• One row per alter (nominated node)
• Filename format: caseID_sessionUUID_attributeList_nodeType.csv, where nodeType is the node type's name as written in your codebook, in any language
• Contains:
  • All alter attributes you collected
  • Network Canvas identifiers (alter UUID, ego UUID)
  • A nodeID number that identifies the alter only within this interview

Example structure:

nodeID,networkCanvasEgoUUID,networkCanvasUUID,name,age,close_friend,contact_frequency
1,abc123,xyz789,John,32,true,Daily
2,abc123,uvw456,Sarah,29,true,Weekly

Important notes:

• If your protocol defines multiple node types (e.g., "Person" and "Organization"), you'll receive a separate file for each type
• The nodeID is numbered from 1 in each interview, across all of its node types, so a file for one node type can skip numbers. The same nodeID belongs to a different alter in each interview
• The networkCanvasUUID is the permanent unique identifier for each alter

Edge attribute list

• One row per edge (relationship between alters)
• Filename format: caseID_sessionUUID_edgeList_edgeType.csv, where edgeType is the edge type's name as written in your codebook
• Contains:
  • Edge attributes you collected
  • Source and target identifiers (both UUID and export ID)
  • Link to ego network (networkCanvasEgoUUID)

Example structure:

edgeID,from,to,networkCanvasEgoUUID,networkCanvasUUID,networkCanvasSourceUUID,networkCanvasTargetUUID,relationship_strength,frequency
1,1,2,abc123,edg001,xyz789,uvw456,strong,high

Important notes:

• The from and to columns hold the nodeID of the two alters the edge connects. networkCanvasSourceUUID and networkCanvasTargetUUID hold their networkCanvasUUID
• Each edge type gets its own file. The edge type is in the file name, not in a column
• If the interview has no edges at all, the export still writes one edge file, caseID_sessionUUID_edgeList.csv, that holds only the header row

Why some values start with an apostrophe

Spreadsheet programs treat a cell that starts with =, +, - or @ as a formula, and can run it when the file is opened. To protect anyone who opens your data in a spreadsheet, the CSV export adds an apostrophe (') to the start of any text value, such as an answer or a case ID, that begins with =, +, -, @, a tab, or a carriage return. For example, the answer -5 degrees is written as '-5 degrees. Column headers get the same apostrophe, so a variable named =total has the header '=total. Numbers and true/false values never get the apostrophe, and neither do GraphML files.

Analysis software reads the apostrophe as part of the text. To remove it from a text column, or from your column headers, remove a leading apostrophe only where it is followed by one of those characters:

# R
alters$notes <- sub("^'([=+@\t\r-])", "\\1", alters$notes)
names(alters) <- sub("^'([=+@\t\r-])", "\\1", names(alters))

# Python (pandas)
alters["notes"] = alters["notes"].str.replace(r"^'(?=[=+\-@\t\r])", "", regex=True)
alters.columns = alters.columns.str.replace(r"^'(?=[=+\-@\t\r])", "", regex=True)

This also removes an apostrophe that a participant typed themselves in front of one of these characters, which is rare.

GraphML format

What it is: GraphML is an XML-based open standard for representing graph data. It stores the complete network structure in a single file.

Best for:

• Network visualization software (Gephi, NodeXL, Visone)
• Network analysis programs (UCINET, Pajek, ORA)
• Graph databases and tools that work with graph structures
• Preserving the complete network structure in one file

What you get:

• One file per interview session
• Filename format: caseID_sessionUUID.graphml (see How export files are named)
• Contains:
  • Complete network structure (nodes and edges)
  • All node and edge attributes
  • Ego attributes (stored as graph-level attributes)

Example structure:

<?xml version="1.0" encoding="UTF-8"?>
<graphml xmlns="http://graphml.graphdrawing.org/xmlns">
  <graph id="G" edgedefault="undirected">
    <node id="alter_1">
      <data key="name">John</data>
      <data key="age">32</data>
    </node>
    <node id="alter_2">
      <data key="name">Sarah</data>
      <data key="age">29</data>
    </node>
    <edge source="alter_1" target="alter_2">
      <data key="relationship_strength">strong</data>
    </edge>
  </graph>
</graphml>

Network Canvas GraphML extensions

Exported GraphML files include a small set of Network Canvas extensions so that interview metadata—such as the protocol used, case ID, and session identifiers—travels with the network data. These extensions are designed for interoperability: GraphML parsers that don't recognize them will simply ignore them.

Session metadata: Namespaced nc: attributes on the <graph> element store session-level metadata:

• nc:caseId
• nc:sessionUUID
• nc:protocolName
• nc:protocolUID
• nc:codebookHash
• nc:sessionExportTime
• nc:sessionStartTime
• nc:sessionFinishTime

The schema nc-types.xsd defines these attributes, and graphml+netcanvas.xsd extends the <graph> element to include them.

The <graph> element also has an nc:finishOutcome attribute, which records how the interview ended. It is left out when no outcome was recorded. See How the interview ended.

Ego attributes: Ego data is stored using the standard GraphML mechanism for attaching data to the graph itself, so no schema extension is needed. Each ego attribute is declared with a <key> element whose for attribute is set to graph, rather than node or edge:

<key id="ego_attribute" attr.name="ego_attribute" attr.type="string" for="graph" />

Note that the <key> element must be located outside of the <graph> element. The attribute is then given a value anywhere inside the <graph> element:

<graph>
  <data key="ego_attribute">Jimbo</data>
</graph>

Because this uses the existing GraphML schema, other parsers either ignore ego data or correctly display it as one or more attributes of the graph itself. Network Canvas parsers treat all graph-level <key> and <data> elements as describing ego.

GraphML attribute names

GraphML requires each attribute name (attr.name) to be a valid XML name token: letters from any language, digits, and the symbols ., -, _ and :. Variable names in Network Canvas can also contain spaces and other punctuation, so the GraphML export replaces each character that isn't allowed with _, and keeps the name as written in the key's <desc> element:

<key id="…" attr.name="contact_frequency__per_week_" attr.type="string" for="node">
  <desc>contact frequency (per week)</desc>
</key>

Names that are already valid, such as close_friend or género, are written unchanged, without a <desc> element. Replacing characters like this doesn't give a warning. Architect refuses two names that would become the same after this replacement, as close friend and close_friend would. If a protocol created before that check has such names, the name that was already valid keeps it, and the other gets a _2 suffix and a warning. See Column names that clash.

Characters removed from GraphML files

XML, the format GraphML is built on, can't store some invisible control characters, such as the null character. Tabs and line breaks are fine. These characters can end up in an answer when a participant pastes text copied from other software. The GraphML export removes them, and shows a warning (see Export warnings):

• When an answer contains one, the warning is titled "Some characters were removed from the GraphML files". It lists each affected interview by its case ID, or by its session ID if it has no case ID, with the variables whose answers lost characters. The list includes "Case ID" if the case ID itself contained such a character.
• When the protocol's own text contains one, in the protocol's name, a node or edge type's name, or a column name such as a variable's name, the warning is titled "Some characters were removed from protocol text in the GraphML files". Because these characters are invisible, it names each one by its Unicode code point, such as U+0007.

CSV files keep every answer exactly as it was entered, so use the CSV export if you need the original text.

Choosing between CSV and GraphML

Our recommendation: Export data in both formats when first working with Network Canvas data. This allows you to experiment and determine which format works best with your analysis workflow.

How the interview ended

Every export records how each interview ended: the outcome you chose on the Finish Screen the interview ended at. Participants never see it.

• CSV: the ego file has a networkCanvasFinishOutcome column. It comes after APP_VERSION and COMMIT_HASH, and before your ego variables.
• GraphML: the <graph> element has an nc:finishOutcome attribute.

The value is one of:

The CSV cell is empty, and the GraphML attribute is left out, when no outcome was recorded. This happens for interviews that were finished before your app recorded the outcome, and for interviews that haven't been finished. The CSV column is always there, even when every cell is empty.

Because the export writes this column itself, Architect won't let an ego variable be named networkCanvasFinishOutcome. If an older protocol already has one, the export writes that variable as networkCanvasFinishOutcome_2 and shows the "Some columns were given new names" warning. A variable named finishOutcome is exported unchanged.

How export files are named

Every file name starts with the interview's case ID and session ID. CSV file names also say what the file holds:

Node and edge type names are used as written in your codebook, in any language, so a node type named 友人 gives a file ending _attributeList_友人.csv. A few changes keep the names safe on every computer:

• Characters that file systems don't allow in file names, \ / : * ? " < > | and invisible control characters, are removed, as are dots and spaces at the end of a type name.
• A type name that Windows reserves, such as CON, PRN, AUX, NUL, COM1 or LPT1, gets an underscore in front of it.
• A file name can be at most 255 bytes long. If it would be longer, the type name is shortened first. Letters outside the Latin alphabet take two to four bytes each, so names in those scripts reach the limit sooner.
• If two files would get the same name, the node or edge type's identifier from the codebook is added after the type name: caseID_sessionUUID_attributeList_Friend_typeID.csv. This happens when two type names differ only in capitalization (Friend and friend, which some computers treat as the same file name), and when a type name had to be shortened or had nothing left after unsafe characters were removed. The identifier belongs to the type, so the same type gets the same file name every time you export. A very long identifier is replaced by a shorter code made from it, which also stays the same each time.

Column names that clash

Architect refuses names that would give two variables the same column in exported data, including names that only become the same once an export writes them (see Names that would clash in exported data). Protocols created before Architect made this check can still contain such names: for example, a variable named support_emotional alongside a categorical variable support with the option emotional, or variables named close friend and close_friend, which become the same in GraphML files once spaces and punctuation are replaced (see GraphML attribute names). A roster column that isn't a variable in your codebook can also have the same name as a variable's column.

The export never merges two columns into one. When two columns in the same file would have the same name:

• built-in columns, such as nodeID or networkCanvasUUID, always keep their names
• the variable that comes first in your codebook keeps the name
• each later column is renamed with the first free suffix of _2, _3, and so on, such as support_emotional_2

Names that differ only in capitalization, such as Age and age, are not renamed. When the export renames a column, it shows a warning titled "Some columns were given new names", which lists each renamed column, the file format, and the name it was written as (see Export warnings).

Export warnings

An export can finish with warnings about changes it made to your data. The export still succeeds. There are three kinds of warning, each with its own title:

Each warning lists exactly what was affected. Where you see the warnings depends on the app:

• Fresco shows each kind of warning in its own notification, which stays on screen until you close it.
• Interviewer shows the warnings in the export dialog, when the file is ready to save. After you save the file, it shows them again in notifications that stay on screen until you close them.

Export options

Network Canvas provides several specialized export options that affect how your data is formatted. You can usually leave these at their default values unless you have specific requirements.

Merge sessions by protocol

This option combines all interview sessions conducted with the same protocol into a single file (or set of files for CSV).

Availability: This option is only available in Interviewer Classic, up to version 6.5—it was removed in version 6.6. Interviewer and Fresco always export each session as separate files—Interviewer packages them into a single .zip archive for download.

When enabled, this creates one combined file per protocol containing all interviews. For CSV exports, you get a single ego file, a single alter file per type, and a single edge file per type. For GraphML exports, you get a single file containing a separate <graph> element for each session—note that most software outside Network Canvas does not support GraphML files with multiple graphs. When disabled, the export creates separate files for each interview session.

Enable this option when you want all your data in one place for analysis, or when you're importing into statistical software that works better with combined datasets. Disable it when you want to analyze individual interviews separately, or when you're doing quality checks on individual interviews.

If your application doesn't offer this option, you can combine the per-session CSV files during analysis instead—for example with dplyr::bind_rows in R.

Even when merged, ego networks remain separate—the data is combined into shared files, but network boundaries are preserved through the ego identifiers.

Use screen layout coordinates

This option adds screen-specific pixel coordinates alongside the normalized node positions recorded by Sociogram interfaces.

Network Canvas stores node positions from Sociogram layout variables as normalized x/y coordinates (values between 0 and 1) with the origin at the top-left. This normalization allows layouts to be displayed on screens of different sizes while maintaining relative positions.

A layout variable is exported as two CSV columns named after the variable, with _x and _y suffixes—a layout variable named layout produces layout_x and layout_y columns containing the normalized values. When this option is enabled, the export keeps those normalized columns and adds two further columns, layout_screenSpaceX and layout_screenSpaceY, containing pixel values (rounded to two decimal places) based on a screen size. In Interviewer, it uses the screen layout width and height you set in Settings → Data export (default 1920 x 1080 pixels). In Interviewer Classic, it uses the screen dimensions configured in its export settings, which default to — and can be reset to — the device's own resolution. In Fresco, it uses a fixed size of 1920 x 1080 pixels. When disabled (the default), only the normalized 0-1 columns are exported. Note that the screen-space Y value is calculated as (1 − y) × screen height, so it is measured from the bottom of the screen—matching the coordinate convention of most visualization software—while the normalized _y column is measured from the top.

Enable this option when you want to recreate the exact visual layout as it appeared during the interview, when you're importing into visualization software that expects pixel coordinates, or when you need coordinates that match specific screen dimensions. Disable it when you want device-independent coordinates that work on any canvas size, when you're comparing layouts created on different screen sizes, or when you want maximum flexibility for visualization.

Example:

Normalized (default), for a layout variable named layout:

nodeID,name,layout_x,layout_y
1,John,0.25,0.33
2,Sarah,0.75,0.67

With screen layout coordinates enabled (1920x1080):

nodeID,name,layout_x,layout_y,layout_screenSpaceX,layout_screenSpaceY
1,John,0.25,0.33,480.00,723.60
2,Sarah,0.75,0.67,1440.00,356.40

If you drew your background in the Background Creator and defined zones there, leave Use screen layout coordinates disabled: its exported Python or R zone-assignment script reads the normalized <layoutVariable>_x / <layoutVariable>_y columns, which are exported by default, and adds a categorical variable naming the zone each node falls in, so you do not have to write that classification by hand.

Additional export considerations

Unique identifiers: Network Canvas generates unique identifiers (UUIDs) for all entities:

• networkCanvasEgoUUID - Unique ego identifier across all sessions
• networkCanvasUUID - Unique alter identifier
• networkCanvasCaseID - Case identifier you provided or auto-generated
• networkCanvasSessionID - Unique session identifier

These identifiers allow you to:

• Merge data from multiple exports
• Link data to external sources
• Track participants across multiple interview sessions (if applicable)

Session metadata: Ego files include valuable metadata:

• sessionStart - Interview start timestamp
• sessionFinish - Interview end timestamp
• sessionExported - Export timestamp
• networkCanvasProtocolName - Protocol used
• networkCanvasFinishOutcome - How the interview ended (see How the interview ended)

Data structure details

For a complete reference showing how each variable type is encoded in these files—column naming, value formats, and missing-value handling—see the Export Data Dictionary.

Understanding the ego-alter-edge structure

Network Canvas organizes personal network data using a standard ego network structure:

Ego (participant)
├── Alter 1 (network member)
├── Alter 2 (network member)
├── Alter 3 (network member)
└── Edges (relationships between alters)
    ├── Alter 1 → Alter 2
    └── Alter 2 → Alter 3

Ego level: One row per participant, containing:

• Participant demographics
• Aggregated network measures (if calculated)
• Session metadata

Alter level: Multiple rows per participant (one per nominated alter), containing:

• Alter attributes
• Ego-alter tie attributes
• Reference to ego (networkCanvasEgoUUID)

Edge level: Relationships between alters within each ego network, containing:

• Edge attributes
• Source and target alter references
• Reference to ego network

Working with multiple entity types

If your protocol defines multiple node types (e.g., "Person" and "Place"), the export structure reflects this:

CSV export:

• Separate alter files: case_001_session_123_attributeList_Person.csv and case_001_session_123_attributeList_Place.csv
• Each file contains only alters of that specific type
• Edges between different types appear in the edge files with appropriate type indicators

GraphML export:

• All node types in one file
• Node type identified by attribute

Handling missing data

Network Canvas handles missing data as follows:

CSV format:

• Optional fields left blank: Empty cell
• Boolean variables not answered: Empty cell
• Multi-select checkboxes not selected: FALSE or empty

GraphML format:

• Optional attributes without values: Attribute tag omitted
• Required attributes: Empty string value

Best practice: Document your protocol's required vs. optional fields so you know which missing values are expected.

Using exported data

Opening CSV files

Network Canvas writes CSV files as UTF-8 without a byte order mark (BOM), the form most analysis software expects. The files can hold names and answers in any language.

Microsoft Excel: When you double-click a CSV file, Excel only reads it as UTF-8 if it starts with a byte order mark. Otherwise accented letters and other scripts look garbled, for example género instead of género. The data in the file is fine. Import the file instead of double-clicking it (Microsoft's guidance):

• Excel for Windows: On the Data tab, in the Get & Transform Data group, choose From Text/CSV. Select the file and choose Import. In the preview, set File Origin to 65001: Unicode (UTF-8), then choose Load.
• Excel for Microsoft 365 for Mac: On the Data tab, choose From Text (Legacy), then select the file and open it. On the first page of the Text Import Wizard, set File origin to UTF-8, then follow the remaining steps.

LibreOffice Calc: When you open a CSV file, LibreOffice shows a Text Import dialog. Choose Unicode (UTF-8) as the Character set.

R: Base R's read.csv reads the files correctly when R runs in a UTF-8 locale, which is the default on macOS and Linux, and on Windows from R 4.2. Otherwise, add encoding = "UTF-8". Two other details matter:

• By default, read.csv changes column names that aren't valid R names: close friend becomes close.friend, and outside a UTF-8 locale género can become g..nero. Add check.names = FALSE to keep the names as written, and quote them with backticks, as in alters$`close friend`.
• Base R reads true and false as text. Convert a column with as.logical(), as in alters$close_friend <- as.logical(alters$close_friend).

alters <- read.csv("case_001_session_123_attributeList_Person.csv",
                   check.names = FALSE, encoding = "UTF-8")

readr::read_csv() and data.table::fread() also read the files as UTF-8, keep column names as written, and read true and false as logical values.

Python: pandas reads the files directly. pd.read_csv() uses UTF-8 by default, keeps column names as written, and reads true and false as booleans.

In R (statistical analysis)

Network Canvas CSV exports are designed to work seamlessly with R, particularly the egor package:

library(egor)

# Read the exported CSV files
# (check.names = FALSE keeps column names exactly as they are in your codebook)
egos <- read.csv("path/to/ego.csv", check.names = FALSE)
alters <- read.csv("path/to/alters_Person.csv", check.names = FALSE)
edges <- read.csv("path/to/edges_friendship.csv", check.names = FALSE)

# Combine them into an egor object, linking the files
# through the Network Canvas identifiers
ego_data <- threefiles_to_egor(
  egos = egos,
  alters.df = alters,
  edges = edges,
  ID.vars = list(
    ego = "networkCanvasEgoUUID",
    alter = "networkCanvasUUID",
    source = "networkCanvasSourceUUID",
    target = "networkCanvasTargetUUID"
  )
)

# Or use the ideanet package, which reads an export folder directly (see tutorial)
library(ideanet)
nc_data <- nc_read(
  path = "path/to/export/folder",
  protocol = "path/to/protocol.netcanvas"
)

If you exported sessions as separate files, combine the matching per-session files (for example with dplyr::bind_rows) before building the egor object, so that each data frame covers all interviews.

See also: Working with Network Canvas Data in R

In Python

Network Canvas CSV exports load directly into pandas, and the per-file identifier columns give you everything needed to join entity files and build graphs with networkx:

import pandas as pd
import networkx as nx

# Read the entity CSVs. Alter and edge rows carry a networkCanvasEgoUUID
# column that links them to their ego's row in the ego file.
egos = pd.read_csv("case_001_session_123_ego.csv")
alters = pd.read_csv("case_001_session_123_attributeList_Person.csv")
edges = pd.read_csv("case_001_session_123_edgeList_Friend.csv")

# A flat analysis table: each alter alongside its ego's attributes
alters_with_ego = alters.merge(egos, on="networkCanvasEgoUUID")

# Build one networkx graph per ego network from the CSV files,
# using the permanent UUID columns as node identifiers
graphs = {}
for ego_uuid, ego_alters in alters.groupby("networkCanvasEgoUUID"):
    G = nx.Graph()
    for _, alter in ego_alters.iterrows():
        G.add_node(alter["networkCanvasUUID"], **alter.to_dict())
    ego_edges = edges[edges["networkCanvasEgoUUID"] == ego_uuid]
    for _, edge in ego_edges.iterrows():
        G.add_edge(
            edge["networkCanvasSourceUUID"],
            edge["networkCanvasTargetUUID"],
            **edge.to_dict(),
        )
    graphs[ego_uuid] = G

Because each session exports its own set of files, a single session's files contain exactly one ego network; the grouping above becomes useful once you concatenate the matching per-session files (for example with pd.concat) into study-level data frames.

Alternatively, read the GraphML file, which contains the complete ego network for a session in one graph. Ego attributes are stored at graph level (declared with for="graph"), so networkx exposes them on the graph's own attribute dictionary:

G = nx.read_graphml("case_001_session_123.graphml")

G.graph              # ego attributes, e.g. {'egoName': 'Enzo', 'egoAge': 40}
G.nodes(data=True)   # alters with their attributes
G.edges(data=True)   # edges with their attributes

In network visualization software

Gephi:

1. Open Gephi
2. File → Open → Select GraphML file
3. Graph displays with all attributes available

UCINET:

1. Import GraphML or CSV
2. Convert to UCINET format if needed
3. Run network analysis procedures

In spreadsheet software

Excel, Google Sheets, LibreOffice Calc:

1. Import each CSV file as UTF-8 (see Opening CSV files)
2. Each file opens as a separate spreadsheet
3. Use networkCanvasEgoUUID to link across files
4. Pivot tables and formulas work with the data

Best practices

During data collection

1. Export frequently: Don't wait until all interviews are complete
2. Test exports early: Export test data to verify format meets your needs
3. Verify data structure: Check that all expected variables appear in exports
4. Document your protocol: Keep notes on variable names and their meanings

File organization

1. Create dedicated folders: Keep exports organized by study, date, or wave
2. Use consistent naming: Develop a naming convention for export folders
3. Version control: Keep track of which protocol version produced which exports
4. Backup regularly: Store exports in multiple locations (local + cloud)

Data integrity

1. Verify counts: Check that the number of participants matches expectations
2. Check for duplicates: Ensure case IDs are unique if intended
3. Validate ranges: Spot-check that variable values are within expected ranges
4. Review metadata: Session times can help identify problematic interviews

Preparing for analysis

1. Export both formats initially: Determine which works best for your workflow
2. Document transformations: Keep notes on any data cleaning or recoding
3. Preserve raw exports: Keep original exports before any modifications
4. Create codebooks: Document variable meanings, especially categorical values

Troubleshooting

Common export issues

Problem: Export button is grayed out

• Cause: No sessions selected
• Solution: Select at least one interview session

Problem: Exported files are empty

• Cause: No data collected for that entity type
• Solution: Verify your protocol collected the expected data; check that interviews were completed

Problem: Can't find exported files

• Cause: Unclear save location
• Solution (Interviewer): Check default Documents folder or recent downloads
• Solution (Fresco): Check browser's download folder

Problem: Accented letters or other scripts look garbled in Excel

• Cause: Excel didn't read the file as UTF-8, which happens when you double-click a CSV file
• Solution: Import the file with UTF-8 as the file origin instead of double-clicking it. See Opening CSV files

Problem: Some text values start with an apostrophe

• Cause: The CSV export adds ' before text that starts with =, +, -, @, a tab, or a carriage return, so spreadsheets don't treat it as a formula
• Solution: See Why some values start with an apostrophe to remove it in R or Python

Problem: A warning says characters were removed from the GraphML files

• Cause: Some answers, or the protocol's own text, contained invisible control characters that GraphML can't store
• Solution: The CSV files keep those answers unchanged. See Characters removed from GraphML files

Problem: A warning says some columns were given new names

• Cause: Two columns in the same file would have had the same name, so the export renamed one of them with a suffix such as _2. This can happen with variable names in an older protocol, including names that only become the same in GraphML files once spaces and punctuation are replaced, or with a roster column that isn't a variable
• Solution: See Column names that clash

Problem: Missing variables in export

• Cause: Variables defined but not used on any stages, or validation prevented completion
• Solution: Verify variables are actually used in protocol; check that forms were completed

Problem: Alter IDs don't match between files

• Cause: Using nodeID instead of networkCanvasUUID. nodeID is numbered from 1 in every interview, so the same number belongs to a different alter in each one
• Solution: Use networkCanvasUUID to tell alters apart when you combine files from several interviews or exports. Use nodeID only within one interview's files, for example to match the from and to columns of its edge files to its alters

Data quality checks

After exporting, verify:

1. Record counts match expectations

   • Number of ego records = number of completed interviews
   • Alter counts seem reasonable
   • Edge counts make sense given network size

2. Variable completeness

   • Required fields are populated
   • Optional fields show expected missingness
   • No unexpected missing data patterns

3. Value ranges

   • Categorical variables use expected categories
   • Numerical values within realistic ranges
   • Dates are reasonable

4. Identifier integrity

   • Case IDs are unique (unless repeat interviews intended)
   • UUIDs are present for all entities
   • Ego-alter-edge linkages are valid

Related concepts

• Protocol and Data Workflows - How protocols and data move through each way of running a study
• Interviewer Online and Offline Workflows - Deploying protocols to devices and collecting their data, with or without internet
• Using Fresco - Export data from Fresco-based studies
• Working with Data in R - Detailed tutorial on analyzing Network Canvas data in R
• Variables - Understanding the variables you'll see in exports

Next steps

Now that you understand data export, you can:

1. Export test data from a sample interview to verify format
2. Practice importing exported data into your analysis software
3. Review the Working with Data tutorial for R analysis workflows
4. Plan your data organization strategy for your study