DataTile accepts a variety of input formats, such as Excel and CSV. However, these text-based formats can be prone to errors, especially when used for tracking surveys and syndicated studies.

You can maintain tracking databases by uploading files manually via the interface or pushing them via API.

DataTile fully supports all types of characters and symbols in variable names. However, we recommend restricting characters to ensure compatibility with other solutions and locales that might be used alongside DataTile. Following these guidelines facilitates seamless data flow across suppliers and systems internationally.

To ensure compatibility, we advise restricting variable names in DataTile to the following:

These recommendations can enhance compatibility and streamline data integration across different tools and platforms when using DataTile.

In DataTile, there are limitations on the length of labels as follows:

It is common practice to incorporate category labels of dichotomous multi-response sets into variable labels using the format: {{QUESTION_TEXT}} - {{CATEGORY_LABEL}}.

If variable labels exceed 1024 characters, it is recommended to trim the common part of the question text rather than the unique part that identifies the category. Doing so lets you retain the crucial information that helps identify the category.

DataTile has the capability to derive category labels when creating multi-response sets automatically. Therefore, keeping category labels intact can save significant time and prevent issues with label management after loading the data.

By following this approach, you can effectively manage label length limitations while preserving essential information and simplifying the labeling process in DataTile.

Variable and value labels do not participate in data tracking and matching. Labels in DataTile, once created in a database, prevail over those provided in the subsequent uploads.

You can edit existing labels directly in DataTile, update them in bulk by importing an Excel codebook, or instruct DataTile to override labels when replacing data in the database (see below).
​

DataTile maintains the registry of files imported into its database by generating a virtual variable, $META_VOLUME. The categories within this variable represent the files loaded into the database, and each interview is linked to its respective category.

Like any standard variable, you can modify the labels of the $META_VOLUME variable and its associated categories. DataTile automatically removes the related interviews and the corresponding category from the $META_VOLUME variable if a data set is deleted from the database.
​

When importing new data files into an existing database, DataTile strives to align the variables from the uploaded file with those already present in this database, effectively integrating everything into a single consolidated database.

Consider it like a data processing task where you're merging two SPSS files into a single dataset. The resultant dataset would comprise a union of all unique variables and the categories within these variables.

The examples below demonstrate typical situations, with the presumption that the tracking survey includes a "Top of mind" [tom] question (e.g., "What is the first brand that comes to mind when you think about soft drinks?").

The table on the left represents the data structure in the DataTile database, while the right table depicts the structure of the corresponding variable from the SPSS file that we're integrating into the database.

Case 1.
Identical variables. Nothing special is happening. DataTile concatenates the tom column vertically. Value labels aren’t affected.

Case 2.

AquaZen is coded as ‘1' in the first wave, but in the new SPSS file '1' stands for 'Jumbo Cola’. DataTile will ignore inconsistency in labels and amend everything as AquaZen.

Case 3.

NectarNation [4] was asked about in the first wave but omitted in the second. Alpenkrone [6] was added to the questionnaire in the second wave.

The resulting database after the merge will contain all 6 brands in the ‘tom’ variable.

Case 4.

In case of a spelling mistake, DataTile won't be able to find a match for the 'tom' variable in the second wave. As a result, the final database will include both 'tom' and 'topm' variables.

The 'tom' variable will have missing values for the second wave, while 'topm' won't have any values for the first wave. Although this error causes inconvenience, it's not as significant as in Case 2, because it's easily identifiable. The solution is to rename it and reload the second wave.

DataTile determines the type of variables upon the creation of a database. Change of a variable type only be made through a complete database reload. So it is best to keep the types of variables consistent across all waves.

While it's feasible to map variables and values from SPSS files to different ones in the DataTile database (e.g., mapping "sex" to "gen", and "regions" to "geo"), maintaining consistency in names and category values is highly recommended.

The same logic should be applied to brand lists and category codes that are supposed to be traced across waves. Keep tables of categories consistent for all waves.

DataTile can automatically manage multi-response sets based on naming patterns when new variables are added to the database.

Ensuring unique naming conventions for variables that comprise the same multi-response set is crucial for automation and human readability.

As a suggestion, use a common prefix for the names of variables within the same multi-response set, and append the brand code as a suffix.

For example, using a pattern like PA_1, PA_2, PA_3, ... is a clear and effective naming convention for the "Prompted Awareness" question. While any naming pattern can be used, applying it consistently within its specific multi-response set is essential.

An alternative pattern like QS12_B1, QS12_B2, QS12_B3, ... may work equally well for DataTile, but could be less intuitive for human interpretation.

Here’s an example. Let’s assume we ask respondents to rate each statement for each brand.

So we have statements and brands (which should be consistently coded over the waves, as previously outlined).

Responses to these questions will be recorded in N = [No of brands] x [No of statements] variables. We advise defining labels for the values of these variables.

Here's a proposed naming convention for this set of questions:

In this scenario, we iterate across two lists (brands and statements), forming a consistent pattern that makes it easy to associate each variable with a respondent's choice.

This case is akin to the previous one, but we measure Attitudes, Statements, Brand Image, or Attribution instead of scale.

This data will be captured as a set of dichotomous variables. As before, we recommend using a pattern to match each variable to its corresponding statement and brand by name.

You might have a set of such tables for each product in more complex scenarios. For instance, when questioning about attitudes towards products manufactured by the brands.

In such cases, a three-tier naming pattern should be employed for your questions to iterate over brands, products, and statements.

Here's a potential pattern for such a situation: QS24_BR#_P#_S#, where # is the code of the respective category.

The number of variables to capture responses would be
​N = [No of brands] * [No of products] * [No of statements].