Survey processing: variable codebook, checks and tables

1. Loading the data

Paste columns directly from the sheet (including the header row) – select them in Excel, copy, and paste here:

When to use?

When there is a survey response file – a questionnaire that each respondent answered once – and you want the "book of tables": a frequency table for each question, in questionnaire order, with percentages on a defined base, and at the end the characteristics of the respondents. This is the basic report of every survey, and usually also the appendix to the findings chapter. The page handles single-response questions (the respondent chooses one option) and background variables, multiple-response questions (a column for each option), item batteries on the same scale, and questions asked of only some of the respondents (eligibility). What is not yet covered – below.

The difference from the page frequencies and descriptive statistics: there one variable is described in depth – frequencies, measures of center and dispersion, histogram and the normality assumption. Here – many questions at once, in report order, with a variable codebook and an intake report before them. Both pages read the same file.

The workflow – from the file to the report

The survey processing workflow, as defined for this module, goes through nine stages: opening a study and a variable codebook; intake and merging of files; cleaning, eligibility and recoding; weighting; saving the database for analysis; tables; formatting and exporting the report; dedicated export for the client; delivery and reproduction. In the first stage of the module the page covers what is marked in the table:

The variable codebook

Before entering or analyzing, prepare a codebook: "a summary of the instructions you will use to convert the information obtained from each participant into a format that the software understands" (Pallant, 2020, Chapter 2). Pallant's codebook (Table 2.1 there) is exactly the page's codebook: the variable name in the file, a description (the question wording), the coding instructions (1 = male, 2 = female), and the level of measurement – nominal, ordinal or continuous. On the site – the codebook sheet (legend) of the standard template: variable name | description | variable type | values and coding | notes. The page reads it, adds what can be learned from the data themselves, and displays the result for editing.

Rules the codebook enforces. A unique variable name for each question, starting with a letter, without spaces (Pallant, 2020, chapter 2 – the SPSS naming rules; the template also accepts Hebrew). The first variable – an ID: "a unique number that identifies each case", also written on the questionnaire, so that it is possible to go back to it when an error is found (ibid.). Coding of the responses – a number for each option, in the order of the options in the questionnaire; "other" gets its own code (Pallant gives 99; ibid.). The numbers in the coding are arbitrary – "they represent names", so the variable type is nominal even when it is numeric (Field, 2024, Section 4.6.5).

The type determines the table. Categorical and ordinal – a frequency table (n and percentage; for ordinal also cumulative percentage). Multiple response (item) – one 0/1 column from a question in which several options can be marked; all the items in the same "set" get one table (below). Ordinal items in the same "battery" – one table (below). Continuous – a statistics table (N, mean, standard deviation, median, minimum, maximum), because age or years of seniority have no "categories"; a frequency table of age requires first binning into groups (coding responses). Text (open question) – not tabulated; the page records how many answered, and the answers are coded separately – Pallant: scan the answers, identify recurring themes, give each theme a code and "other" to the rest (2020, chapter 2). ID – not included.

The edits are saved. "Download the file with the updated codebook" returns the data as loaded with a new legend sheet – the question wordings, the types, the codes and the "not a substantive answer" and "background variable" marks in the notes column. This is the file to bring next time, here and to any other calculator on the site.

Missing values and "don't know" codes

Two different things. A missing value – the respondent did not answer, the question was not asked, or the data were not recorded. The site's rule: an empty cell (the standard template, rule 4); Pallant: "the software will recognize any empty cell as missing data", so no special code is needed (2020, chapter 4). A "don't know" or "refused" code – the respondent answered, but not with a substantive answer. In surveys it is customary to give it a code (9, 99) and to document it in the legend like any other code. Field: anyone using such codes must choose an "impossible value" – larger than the maximum of the scale – and tell the software that it is missing, otherwise "the software will treat it as a legitimate value"; SPSS allows up to three discrete codes, each with a different meaning – not applicable, don't know, no answer (2024, Section 4.6.8; Pallant, 2020, Chapter 4).

The page identifies such codes by the label in the legend ("don't know", "refused", "not applicable", don't know, refused…) and marks them in the codebook in the "not a substantive answer" column – this can be corrected. The default: they are excluded from the percentage base and reported in the table note, exactly as MISSING VALUES in SPSS excludes them from Valid Percent. The workflow document distinguishes between "not asked, refusal, don't know and technical missing" – a distinction that can be kept with separate codes in the legend; at this stage the page treats them all the same way (outside the base or as a row, as chosen).

Data checks before the analysis

"It is very easy to make mistakes when entering data, and unfortunately a few errors can completely distort the analyses" – entering 35 instead of 3 (Pallant, 2020, Chapter 5). Pallant describes two steps: checking – for each variable, values outside the possible range; and finding and correcting – in which record the error is. The check for a categorical variable is a frequency table with minimum and maximum: if sex is coded 1-2, a value of 3 is an error; for a continuous variable – Descriptives with minimum, maximum and mean: age 2 in a sample of adults is an error, and "does the mean make sense?" (ibid.). Also check the number of valid and missing values – "if there are many missing values, you need to ask why" (ibid.).

What the intake report checks (Table 1 in the report): for each variable – how many valid, how many empty, how many "don't know/refused", how many distinct values; values that are not in the list of codes in the codebook; out-of-range values of a continuous variable; non-numeric values in a numeric column; categories that no one chose; a constant value; and a duplicate ID – according to the workflow, "an ID that recurs in two sources is not deleted automatically without a suitable rule". The page reports and does not correct: Pallant – sort by the variable, find the record, go back to the original questionnaire and correct, or delete the value (it becomes missing); record it in the log; and also check the adjacent columns of the same record; and after the correction run again, because "in correcting one error you can create another" (2020, chapter 5). An out-of-range value stays in the computation of the statistics until you correct it – so that it does not "disappear" without a decision.

The percentage base

The central question of every survey table: a percentage of whom? According to the workflow, "for each table, define whether the percentages are of the eligible respondents, the respondents with a valid answer or all mentions". The three options on the page:

• Respondents with a substantive answer (the default) – without those who did not answer and without "don't know". This is the Valid Percent of FREQUENCIES in SPSS when the "don't know" codes are defined as missing (the output in Pallant, 2020, chapter 5, shows Percent and Valid Percent side by side), and what the old TABLES command gave with GBASE=CASES with empty missing values. "Don't know" and those who did not answer are reported in the table note – so that the reader sees how many were excluded.
• Everyone who answered – "don't know" stays as a row in the table. Suitable when its rate is itself a finding (e.g., awareness of a service).
• All respondents – including those who did not answer, as a "no answer" row. Suitable for a question everyone was supposed to answer, when non-response is information.

A question asked of only some of the respondents (in the example: satisfaction with the handling – only those who contacted the call center) gets a small base, and the page notes this; at this stage eligibility is derived from the empty values, and not from a skip condition defined in the codebook – that is stage 2 of the module. Rounding. The percentage is rounded to one decimal (or to a whole number) in integer arithmetic, half up – like the PCT5.1 format in the TABLES command – so the column total can come out as 99.9 or 100.1; the "Total" row always shows 100 and the base, as the workflow requires ("a total of about 100% is expected, according to the chosen base and the rounding").

Eligibility and skips – who was asked?

A questionnaire has questions that only some of the respondents were asked: "If you contacted the call center – how satisfied are you with the handling?". According to the workflow, "who is supposed to answer each question" is set in advance, and "skip conditions from the questionnaire are applied; not asked, refusal, don't know and technical missing are distinguished". On the page – an "asked if" field in the codebook: variable = value or several values separated by commas (e.g., q2_digital = 2, 3, 4). In the legend, write this in the notes column in the same form ("asked if q4 = 1"), and the page reads it by itself.

What the condition does: the eligible – those who meet the condition – are the population of the table; those who were not asked are not counted as missing. Among the eligible, those who answered, those who answered "don't know" and those who did not answer are counted, and the base is chosen as usual. The table note says "asked only of those who… – N eligible". And what about someone who answered although they were not supposed to be asked? The intake report counts them ("answered although not asked") – usually a contradiction between the answer and the filter question, or a missing value in the filter question – and their answers are outside the base until you correct them. Without a condition, such a question gets many "empty" values and a small base without explanation – the two things the table note is meant to prevent.

Multiple response

"Which services have you used?" – the respondent marks several options. In the file this is a column for each option, 0 = not marked, 1 = marked (Q4m1 … Q4m4 in the scripts; a "multiple dichotomy set" in SPSS). In the codebook: the type "multiple response (item)" and a set name shared by all the items of the same question (in the legend: "set q7"); the page also detects by itself 0/1 columns with a common prefix (q7_1, q7_2…). The code counted as "selected" is the code whose label is "marked"/"yes"/selected, and if there is no legend – 1.

The table: a row for each option, n = how many marked it, % of respondents = out of those who answered the question (marked at least one option, or 0 explicitly) – and the total exceeds 100, because each respondent is counted in every option they marked; this is the percentage that is reported ("Percent of cases" in MULT RESPONSE, rpct in the scripts). % of mentions = out of all the marks, sums to 100 – describes the mix of mentions, not how many people. The "Total mentions" row gives both numbers and the mean per respondent. The workflow: "in percentages of respondents in a multiple-response question the total can exceed 100%", and "an actual, unweighted number of respondents is shown". The "all respondents" base selects all the eligible, including those who marked nothing.

Item batteries

Several statements on the same scale ("How much do you agree: …", 1-5) are reported together: one table – a row for each item, a column for each category (row percentages), and then the item's N and M, the mean of the codes. This way the battery is read at a glance and items are compared. In the codebook: a shared battery name (in the legend: "battery q8"); the page also detects by itself ordinal items with the same list of codes and a common prefix. The base for each item separately – the item's respondents with a substantive answer (without "don't know" and without empty values; according to the workflow, "a suitable base for each item"), and an eligibility condition, if any, applies to each item.

The mean is shown as a summary measure only, following the site's convention for a single Likert item: an ordinal scale, whose mean is a common shorthand and not an interval measurement (see variables, measurement scales and research designs). A scale score from several items – in Cronbach's alpha and scale score; if you want to know whether the items measure one thing – there.

Merging files – a second wave, an additional source

A survey collected in several files (a telephone wave and an online wave, two vendors, two periods) is merged by rows: the same questions, additional respondents – like ADD FILES in the scripts (there three SAV files with a source variable seker). This is different from joining information about the same respondent across files by ID (MATCH FILES), which the page does not do. On the page: load the first file, and then "Add a response file to merge" – as many times as needed. Columns are matched by name, not by position: a column missing from one file stays empty for its respondents, and a column found only in the second file is added at the end; a "source" column (1, 2, …) is added with the file names as labels – it is tabulated as a background variable, so the record count for each source is in the report. The legend is taken from the first file that has one.

According to the workflow, the controls of the merge are "matching of variable names, data types and response codes across the sources; number of records in each source and in the merged file; duplicates by ID". The merge report (below the button) counts records for each file, missing and extra columns, and type mismatches – text in one file and numbers in another (a sign of different coding: "man/woman" versus 1/2). Different codes for the same question (1-5 in one file, 5-1 in the other) the page cannot detect – this is a check done against the two questionnaires, and it can be fixed by recoding by source. An ID that recurs in two files appears under "duplicate ID" in the intake report and is not deleted: "an ID that recurs in two sources is not deleted automatically without a suitable rule". "Cancel merge" restores the first file; the source files themselves do not change.

Filtering records and recoding – the preparation log

Filtering is the study's eligibility rule: anyone who does not meet it is not part of the reported sample (in the scripts' example – SELECT IF(edu >= 1)). Write one rule per line: age >= 18, area = 1, 2, 3, status <> 9, age 18-85. An empty (or non-numeric) value in the filter question does not meet the rule – the record is excluded, as in SPSS, where a missing value in SELECT IF is not selected; so first check how many missing values there are in the filter variable. Each rule is recorded in the log with the number of records it excluded and the number remaining, as the workflow requires: "eligibility and filtering rules are applied, and how many records were excluded and why is documented". The filtering applies to the tables, to the sample paragraph and to the N in the report header ("240 loaded; 1 excluded by filtering") – not to the intake report, which describes the file as loaded.

Recoding creates a new variable and keeps the original ("derived variables are created while keeping the original variables"; Pallant, 2020, chapter 8: choose specifically Recode into Different Variables so that the original variable remains for other analyses, and after recoding run Frequencies on both the old and the new variable and check that the numbers match – exactly what the report shows side by side): groups of a continuous variable – age_group "age group" = age: 18-29 = 1 "18-29"; 30-44 = 2 "30-44"; 45-64 = 3 "45-64"; 65-85 = 4 "65 and over"; merging categories – education_2 = education: 1, 2 = 1 "non-academic"; 3, 4 = 2 "academic". The new name before the "=" sign, a label (optional) in quotation marks, after the colon the mapping rules separated by semicolons, and "else = 9" (optional) for everything not mapped. A value that was not mapped, with no "else" – empty, and counted in the log ("not mapped 1"); this way an error in the ranges (age 7, which is in no group) is not swallowed. The new variable joins the codebook (ordinal type when the mapping is by ranges or when the source is ordinal; this can be changed), the intake report, the tables report – next to the source, to see the distribution before and after – and the downloaded file (a column in the data sheet (data), a "derived from" note in the legend, and a "preparation" sheet with the log). The order is fixed: first the recoding on all records, then the filtering – like RECODE and then SELECT IF; so a filter rule can also use a derived variable. What is not here: complex conditions (two variables in one rule), computations (a sum of items – in Cronbach's alpha and scale score), and coding open answers (coding responses and creating variables).

Weighting – when, how, and what to check

A sample whose composition differs from the population (more women, fewer young people, one region over-represented) is weighted so that each group gets its share of the population. In the institute's scripts the weighting is by the cell method: for each cell (gender × age, religiosity/origin, region) weight = target percentage / sample percentage, and the final weight is the product of the components (ww = w · w_d · w_az, and then WEIGHT BY ww). The page does exactly this: write one component per line – sex * age_group: 1,1 = 10; 1,2 = 12; … or area: 1 = 35; 2 = 25; … – with the target for each cell (a percentage or a number; the page normalizes from the total). According to the workflow: "for a new study, enter the target distributions, their source and their effective date" – record the source and the date in the report; the numbers in the example are for the sample data file only.

What happens to a record with no cell – an empty value in the weighting variable, or a code not in the target (e.g., sex code 3): its component is 1, like "comp w = 1" in the script, and it is counted in the weighting table ("not assigned"). The workflow warns explicitly: "the weight components start at 1, so records that did not get a match must be checked explicitly". A target cell with no respondents – a warning: this share of the target is not represented; merge cells or document it.

What to check – the weighting table (target, n, sample, weight for each cell), the range of the weights and their mean, the sum of the weights (the weighted base), and the design effect of the weights, deff = 1 + CV² = n·Σw² / (Σw)² – how much precision is lost due to unequal weights (a deff of 1.5 means precision like that of a sample smaller by ⅓). And a before/after check: for each weighting variable – unweighted percentage, weighted and target. In a component that is a cross the margins are obtained exactly; with two separate components – approximately, because "a product of three components does not guarantee that all target distributions are obtained simultaneously; this is checked in practice". Trimming weights to a range (e.g., 0.3-3) and normalizing to a mean of 1 are options turned off by default: "moving to a different weighting method, normalization or trimming of weights requires a methodological choice and documentation" – when enabled, this is recorded in the weighting table, in the sample paragraph and in the "preparation" sheet.

How to read a weighted report – in every table n is the actual number of respondents, and the percentages (and in the statistics table – the mean, SD and median) are weighted; in the note of each table – the weighted base (the sum of the weights). "An actual, unweighted number of respondents is shown, and in a weighted report the weighted computation base is also stated; the sum of the weights must not be called an actual number of respondents" (the workflow, stage 6). The order: merging → recoding → filtering → weighting (the weights are computed on the records remaining after filtering – as in the script, where SELECT IF precedes the weighting). Weighting corrects the composition of the sample, not those who did not respond at all: generalization to the population still requires a probability sample (samples and sampling).

The research package, delivery copy and reproduction

The workflow distinguishes between the full check output – "first check the full output and save it" – and a delivery copy: "question order, titles, labels, bases, method notes and English formatting", without the warnings (this is what MAKEWAR did in the scripts – removed notes, logs and warnings before saving the final report). On the page: "Download report" gives the full output (intake report, preparation log, weighting tables, all the tables, the sample paragraph, the interpretation of the results); "Delivery copy" – only the tables, their notes and the sample paragraph, without "to check" in the notes. The warnings do not disappear: they are kept in the full output – "the warnings are kept in the check package even when they are not shown in the client report" (stage 9).

The research package (ZIP, a button at the end of the report) is what stage 9 requires for delivery and reproduction: the data for analysis with the codebook, the log and the settings (01_data_dictionary.xlsx), the full check output (02), a delivery copy in Word and HTML (03), SPSS syntax that reproduces everything (04), an R script (05), the settings as a separate file (06_settings.json), the export file according to the specification if defined (07), and a README.txt detailing what is in each file, the state of the data (loaded/in analysis, intake findings, preparation, weighting, options) and how to reproduce. The file names are in English – so that they open on any system.

Reproduction. "The outputs can be reproduced from the same inputs and settings" – so the settings are saved in two places: the "settings" sheet in the downloaded file (the codebook with its edits, the coding, the filtering, the weighting, the report options, the export specification) and settings.json. Load the downloaded file – and the settings are loaded automatically (a message on loading); or load the source file and then "Load settings from file". A derived variable that already exists as a column in the downloaded file – is not built again (it is already there, with the "derived from" note in the legend); the saved weight column is not tabulated, and the weight is recomputed from the components – so the reproduction check is real: the same numbers from the same settings. A change in a setting requires producing the report again (stage 5: "a change in cleaning or weighting requires producing again the tables and the report that depend on them") – the page recomputes everything on each run, so there is no situation of an old report with new settings.

Export to a client specification (section 7) – when a client requires a text file with fixed column positions, like Tires-Write_perfecto.SPS, which wrote TyreBrands.txt. According to stage 8: "before the export, define a specification: … column positions, width of each field, character encoding, representation of missing values and order of the records. Create a new file, check lengths and positions and read it back according to the specification." On the page: one field per line (variable and width, or start-end), a character for missing, and an option for a weight field; the file in UTF-8, a line for each record in the analysis, in file order. A value wider than the field is not truncated silently – it is recorded as an error and the field stays empty, so that you widen the field. The structure check is the read-back: each field is read from the positions in the specification and compared with the data; the report counts mismatches and line lengths. The export specification is written to a separate file in the package. Hebrew text in a fixed-width field is counted in characters (not bytes) – if the client requires windows-1255 encoding or width in bytes, convert after downloading and state this in the specification.

How to read the table?

The table title – the question wording (like /TITLE in the TABLES command). In the categories column – the label followed by the code in parentheses, so that it is possible to go back from the table to the file. n – the number of respondents who chose the category; % – out of the base; Cumulative % (for ordinal variables) – up to and including this category, useful for "how many are satisfied or very satisfied" (adding the last two rows). The "Total" row – the base and 100%. The table note – what the base is, how many answered "don't know", how many did not answer.

Three things worth looking at before continuing: a category with 0 – no one chose it; according to the workflow this is a check ("categories with zero responses"), so the category is shown by default and does not disappear. A row without a label – a value not in the codebook (a data-entry error or an undocumented code); the intake report flags it. A small base – a percentage based on 20 respondents moves by 5 points with each respondent; report the base next to each percentage, and in the text prefer the numbers.

The statistics table for a continuous variable: N, mean, standard deviation (with denominator n − 1), median, minimum and maximum – like DESCRIPTIVES in SPSS, and with the median that Codebook adds (Pallant, 2020, Chapter 6). The mean and the standard deviation to two decimals, as in the software; APA recommends one decimal for data on an integer scale (2020, section 6.36) – round in the report.

Reporting

The tables on the page are built according to APA: a table number and title above, a heading for each column including the "stub" column (the categories), and a general note below explaining the base (APA, 2020, Sections 7.12 and 7.14). The table of respondent characteristics – Table 7.2 in the manual, "sample demographic characteristics table": variable after variable, the categories indented under the variable name, and n and % for each category (ibid., section 7.21; the indentation – section 7.12). On the page each background variable is a table of its own; in a combined report they can be merged into one table in this structure, when copying to Word.

The sample-description paragraph that the page drafts is the opening of the method chapter: Pallant notes that in research with participants "it is useful to collect information on the number of people in the sample, the number and percentage of men and women, the range and mean of age, level of education and any other relevant background information" (2020, chapter 6) – and this is what the paragraph collects from the marked background variables. Write the report's numbers as they are in the table; the reporting rules and the findings chapter generator complete the rest.

What the page does not do (yet)

• Multiple response in categorical coding – when instead of a 0/1 column for each option there are several columns "mention 1, mention 2…", each with an option code (a multiple category set in SPSS). At this stage – dichotomous coding (0/1) only.
• A complex eligibility condition – two variables ("asked if q4 = 1 and also q2 = 3") in one condition; in filtering – each line is a rule, and they all apply together (and), but there is no "or".
• Joining files by ID (MATCH FILES – information about the same respondent from two files) and computed variables (sum, mean of items) – no; merging is by rows only, and recoding – a mapping of one variable.
• Weighting by other methods – raking (iterative proportional fitting), which fits several margins simultaneously, sampling weights (inverse selection probability), model-based nonresponse weighting – no; only the cell method of the scripts. Weighted confidence intervals and tests (the design effect in computing the standard error) are also not on this page.
• Export to the client in a card structure (record types, card code, several lines per respondent, windows-1255 encoding) – no; only one line per record in fixed width in UTF-8.
• Breakdowns – the table by group (BY kk in the scripts when the columns are subgroups) – not here but on the follow-up page, survey processing: breakdowns: load there the file downloaded from here (with the "settings" sheet), choose column banners and get all the tables by groups with chi-square and V for each crosstab. For one detailed breakdown – chi-square.
• Charts for each table – available, as an option; the frequencies page gives a chart and a full figure note for one variable.

And how do you do it in SPSS?

For the tables – Analyze › Descriptive Statistics › Frequencies: enter the questions and click OK; the output is a table for each variable with Frequency, Percent, Valid Percent and Cumulative Percent (Pallant, 2020, Chapter 6). For Valid Percent to be "respondents with a substantive answer", define the "don't know" codes in Variable View › Missing (Field, 2024, Section 4.6.8) – the syntax the page downloads does this with MISSING VALUES, together with VARIABLE LABELS and VALUE LABELS from the codebook. For the checks – Frequencies with Statistics › Minimum, Maximum for categorical variables and Descriptives for continuous ones (Pallant, 2020, Chapter 5); all the information about the codebook in one command is given by Analyze › Reports › Codebook (ibid., chapter 6) – also in the syntax. A conditional question – TEMPORARY and then SELECT IF before its FREQUENCIES (the syntax does this for every question with "asked if"). Multiple response – Analyze › Multiple Response › Define Variable Sets (dichotomies, counted value 1) and then Frequencies; in syntax – MULT RESPONSE GROUPS=$q7 (q7_1 q7_2 q7_3 q7_4 (1)) /FREQUENCIES=$q7, and the Percent of Cases column in the output is "% of respondents" on the page. A battery – FREQUENCIES for all the items with /STATISTICS=MEAN; the combined table (items in rows, categories in columns) is assembled in CTABLES or manually – the syntax gives the numbers. Merging files – Data › Merge Files › Add Cases; in syntax – GET DATA for each file with COMPUTE source = k and DATASET NAME, and then ADD FILES /FILE=src1 /FILE=src2 (as in the script 070410_all-sys). Recoding – Transform › Recode into Different Variables; in syntax – RECODE age (18 thru 29=1) (30 thru 44=2) … INTO age_group with VALUE LABELS (Pallant, 2020, Chapter 8). Filtering – Data › Select Cases, or a permanent SELECT IF (age >= 18) (without TEMPORARY) before the tables; weighting – COMPUTE w1 = 1 and then IF (sex = 1 AND age_group = 1) w1 = target / sample for each cell, COMPUTE ww = w1 * w2, WEIGHT BY ww – exactly as in the preparation script; from here FREQUENCIES prints weighted frequencies, and the N in the output is the sum of the weights (not a number of respondents – so the page prints the actual n alongside). The syntax arranges everything in the right order: loading and merging, recoding, codebook, filtering, weighting, tables.

And the old scripts? For years the tables report in research institutes was built with the TABLES command: for each question /TABLE= q5 + $t000001 BY kk, column percentage (cpct) in the PCT5.1 format, a total row (FTOTAL), GBASE=CASES, empty missing (MISSING('.')) and the question wording in /TITLE – and a script that generates all the commands from the codebook (Create_Freq). The page's table is exactly this table: the same rows, the same base, the same rounding. TABLES no longer exists in current SPSS versions (it was replaced by CTABLES), so the syntax the page downloads uses FREQUENCIES, which exists in every version – and also in the free PSPP.

And how do you do it in R?

No special packages: table() for counting, and the percentage is computed by rounding to one decimal in integer arithmetic as on the page. The script the page downloads ("Download R script") reads the file with readxl, defines a function freq_table that excludes NA and the "don't know" codes from the base, and prints a table for each question and statistics for each continuous variable; for a conditional question – filtering with %in%; for multiple response – colSums on rows with at least one value; for a battery – a table and a mean for each item; for merging – rbind after filling in the missing columns with NA; for recoding – assignment by ranges or %in%; for filtering – selecting rows; for weighting – a vector of weights from the cells, tapply(w, x, sum) for a weighted table and a manual weighted mean (SD with denominator W − 1, as in SPSS). The site's rule for R scripts: a UTF-8 file, every comment line starts with an English word, and English variable names (the English sample data file). Note: in this build round R was not available, and the script was checked by reading only – the page's verification was done against Python (pandas); see the verification README.

Common mistakes

"Don't know" inside the base without noticing. A code 9 not documented in the legend is counted as an answer – and inflates "dissatisfied" or appears as an obscure row. Field: an undefined missing value "will be treated as a legitimate value in every analysis – with disastrous results" (2024, section 4.6.8). So the codebook shows these codes in a column of their own.

Tabulating an open question or a continuous variable. 200 different answers are not a table. Age is tabulated after binning; text – after coding (Pallant, 2020, Chapter 2).

Showing percentages without a base. 50% can be 3 out of 6. The base next to every table – and for a question asked of only some of the respondents, in the text too.

Correcting an error without recording it. Pallant: a log of every error found and every change made (2020, chapter 5). The intake report is the beginning of the log – keep it with the report.

Filtering without counting. "We excluded those who were not eligible" – how many? Out of what? The preparation log says: rule, excluded, remaining; and in the method chapter write "of 240 records, 239 were included (filtering: age 18 and over)".

Recoding over the original variable. "Age" that has become groups is no longer age – the mean is lost. Always a new variable; the original stays in the file and in the report.

Reporting multiple response as a percentage of mentions. "37% of mentions were payments" sounds as if 37% of the people – but 54% of them marked payments. Report % of respondents, and say that the total exceeds 100.

Calling the sum of the weights "the number of respondents". The rule in the workflow: show the actual, unweighted N, and in a weighted report also state the weighted base – this is how the page prints it (actual n, weighted percentage, "weighted base" in the note).

Delivering the check output to the client, or delivering without saving it. The client gets the delivery copy; the check output with the warnings stays in the package. And whoever delivered without a package will not be able to reproduce a year from now exactly what was filtered and weighted.

Weighting without checking the cells. A weight of 4 for a cell of eight respondents – eight people "speak" for a quarter of the report. The weighting table shows this before delivery; trimming is a possible answer, but a documented one.

References

American Psychological Association. (2020). Publication manual of the American Psychological Association (7th ed.). https://doi.org/10.1037/0000165-000

Field, A. (2024). Discovering statistics using IBM SPSS statistics (6th ed.). Sage.

Pallant, J. (2020). SPSS survival manual: A step by step guide to data analysis using IBM SPSS (7th ed.). Routledge.

By the site's rule, the reference list includes only sources read in the original: Field – chapter 4 (sections 4.6.1, 4.6.5, 4.6.8), Pallant – chapters 2, 4, 5 and 6, APA – sections 6.36, 7.12, 7.14 and 7.21 (Table 7.2). Both are cited by section and chapter (the e-books do not preserve the printed page numbers). The workflow and the SPSS scripts (TABLES, Create_Freq, inc) are the site's working documents – not published sources, so they are not on the list. The computation on the page is verified against Python (pandas) on the sample data file – every n, every percentage and every statistic, digit by digit, including the multiple-response table, the battery, the conditional bases, the tables after filtering and recoding, the merged file (pandas.concat), the cell weights, the sum, the design effect and the weighted tables (weighted percentages, mean, SD and median).