We have recently released an article in our Knowledge Base detailing all the exciting new features packed into AskiaAnalyse 5.6. This blog post is an accompaniment, promoting the release and summarising the most useful, everyday features it contains.


Filtered Weighting

Filtered weighting removes the need for manual intervention when implementing certain weighting schemes. We have a blog article on this handy new feature here. The article contains a video where I walk through an example that AskiaAnalyse could not handle previously.

In summary, you’ll see these new options in the new version:

A: This allows you to set a sub-population of only the records that will be considered when the weighting scheme is run.

B: For those records that are outside of the sub-population, we need to set a value for these records to be weighted to. Often this will be 1 or 0.

C: The option (B), above, can be set by default in your Analyse options. This means that each new weighting scheme created has the value set here for filtered weight.


Developed sub-questions for calculated loop variables

Calculated/Derived loops have been a success since being introduced in Analyse 5.3.5. With looped variables alone, you can do almost all of the analysis you come across day to day. However, there were one or two specific instances in that time where our clients were stuck and needed to create a derived loop that also had developed questions available to them. So, in the latter part of 2023, we introduced the following options to deal with this gap in functionality:

Any time users now change the level on a calculated question from interviews to that of a loop in the survey, they will see the new option ‘Develop questions in level’ (A) become enabled. If you tick and save you’ll see the developed questions appear now under your original undeveloped loop variables:

We also have the option to set loop shortcuts in the caption section of your variable (B). After saving, these are expanded to put the correct loop item label in the long caption of your developed question. This gives additional flexibility when building tables from developed calculated loops:


New Col Sig option in ‘Test each column against’

A need that arose for a handful of users since the last big version release was in col sig testing. There was a need to be able to carry out col sig tests only between the responses of a question in the edges, and not across all edges. We have the ability to do this with the existing options in columns using ‘All columns of the question’ but since some users put their main banner in edges rather than columns, we felt this new feature would be useful. 

You’ll notice there are two new options shown in the screenshot above.

i) All columns of the edge question

Note that the first edge variable is Agreement and it has three visible responses. In this case the testing remains within the columns related to the current edge variable B1-G1, and repeats for all following edge variables (1. Appreciation → tests H1-Q1, i3. Profession → tests R1-C2). The column response we are on does not matter but it does in the next option.

ii) All columns of the edge question AND the corresponding column response within the edge

Note that the first edge variable is Agreement and it has three visible responses. In this case the testing remains within the columns related to the current edge variable B1-G1. However, in addition, we restrict the test so we only test the same column response each time i.e. Man vs Man and Woman vs Woman. For example, in this case:


Export all decimals in Excel but cell format should match decimal place setting in Analyse

In Analyse we can change the decimal places of a cell output in the following two places:

Previously in Analyse, when you went on to export to Excel, the cells there would contain only the rounded number you set with the options above. 

Having discussed with users through support, it became apparent that more flexibility around this was required.

One may want the cells to be formatted to 3 decimal places and appear like this on first look. However, the full unrounded numbers are often needed to accurately put together further calculations e.g. either done manually in the Excel document or automatically when the Excel output is consumed by another software.

We can now achieve this with the ‘Export rounded values‘ option:

It’s set to ‘Yes’ by default to minimise the risk of back-compatibility issues. So set it to ‘No’ if you want this behaviour. What you’ll now see after exporting is as shown below:


Automation Scripts: Create Calculated Variables

We’re excited to have added another powerful new feature in this version that allows more flexibility and automation possibilities.

Since the earlier versions of Analyse 5.6.1. we could create derived variables by script. Initially we could only create the following variable types with no additional settings:

  1. Numeric by script
  2. Closed by script
  3. Closed by single script

In later versions of Analyse 5.6.1. we we added the ability for automation scripts to set the level & sub-population to a calculated variable as well as create three new variable types:

  1. Find all values of a script
  2. By weighting
  3. Open by script

There is a Knowledge Base article that goes in to more detail covering usage examples here.


New AskiaSurf Features: Selective matching & reconciliation

AskiaSurf is now able to leverage the power of tags, speeding up work on set-ups which have lengthy and/or highly customised matching requirements. Six new parameters have been added and are summarised in the table below:

/IgnoreTaggedSourceQuestions /IgnoreTaggedSourceResponses When the source .QES file added to the existing .QEW/campaign has tags on its questions or responses, you can choose to ignore matching these during reconciliation.
/IgnoreTaggedCampaignQuestions /IgnoreTaggedCampaignResponses When the campaign .QEW file has tags on its questions or responses, you can choose to ignore matching these during reconciliation.
/TagMatchingMethods:"" Specify the question matching methods by tags in the source .QES file. You need to list the name of the tag and the letter code for the question matching method in JSON format (see codes listed under /M: above).
One tag, one method format: /TagMatchingMethods:"[{""tags"": [""tagName1""], ""methods"": ""methodCodeLetter1""}]" Two tags, one method: /TagMatchingMethods:"[{""tags"": [""tagName1"", ""tagName2""], ""methods"": ""methodCodeLetter1""}]" Three tags across two methods: /TagMatchingMethods:"[{""tags"": [""tagName1"", ""tagName2""], ""methods"": ""methodCodeLetter1""}, {""tags"": [""tagName3""], ""methods"": ""methodCodeLetter2""}]"
/MATCH_STRICTLY The default matching is done on first letter code it has success matching on. This new parameter allows you to specify that all matching methods listed must be satisfied for a match to be made.

There are a few usage examples at the end of our Askia Surf from the command line article.

There are many more features in the new release and so would recommended looking at the ‘What’s New’ KB Article, which has all the details and worked examples.

Link to the article: AskiaAnalyse 5.6.