Askia now hiring technical support staff in the UK!

Location

Shoreditch, London.

Description

The primary responsibility of this position is to provide technical support to customers by researching issues, answering questions, and general troubleshooting of problems.  Additional duties will include:

  • Phone, email, and in-person technical assistance
  • Remote and on-site training and installations
  • Pre-sales support (demonstrations and presentations)
Requirements:
General Skills
  • One (1) year Market Research software expertise (survey scripting and/or data processing)
  • Knowledge of data collection and data processing techniques
  • Knowledge of web scripting (HTML, CSS)
  • Knowledge of programming (VBA, JavaScript)
  • Knowledge of databases (SQL, Access)
  • English language required
  • Occasional UK and International travel
Personal Skills
  • Logical thinking and good communication skills
  • Quality oriented with attention to details
  • Self-driven, responsible, and organized with ability to meet deadlines
  • Attention to detail
Additional Skills (not essential)
  • Experience/Knowledge of the Askia Suite of products
  • French/Spanish/German/Italian speaking skills a benefit
  • Dialler and VoIP technologies a benefit
And finally…

We are not looking for “geeks” as we have plenty of those in our development team. We want fun, lively, articulate people to join us in our continued success in supporting our clients

How to Apply

Be the next to join the Askia team by sending your CV to nick@askia.com.

New version 5.3.5.0 of askiaanalyse

This post is the second in a series that detail the key features in version 5.3.5.0 of askiadesign & askiaanalyse. The blog post on askiadesign 5.3.5.0 can be found here.

Much development work has been invested in 5.3.5.0 to take our Analysis software to the next level. A detailed list of these great new features can be found in the version roadmap. Below are a summary and examples of several key developments:


Table of contents:

    1. Table arithmetic (Cleaning script)
    2. Aggregated scripts
    3. Table arithmetic (Calculation arithmetic)
    4. Table suppression
    5. Paste captions
    6. New keywords in script calculations
    7. New options in level

For items 1 to 3 there is a range of articles on our help centre which go into a greater amount of detail than we will in this post. The objects, properties and methods for the new scripting language are summarised in this document.

 


Table arithmetic (Cleaning script)

The ‘Cleaning script’ is a process that runs immediately after your table is created. It changes the appearance of a table based on the figures it has in it. So, for example, you can have sophisticated conditional formatting or fill text and numbers into cells of your choice using syntax. Here I will demonstrate how to change the default column significance lettering to display a shape of a particular colour.

In the table below we are testing each column against the total column only – we can see if it is significantly different by the letters returned from some of the pre-set options: higher (“A+”) or lower (“-A+”).

clean2

What if the requirement is to show something other than these pre-set options e.g. a green ▲ for higher and a red ▼ for lower

The ‘Cleaning script’ window is found in the Tab definition > General tab > Settings > Sorting. We can achieve this requirement by adding the script below. It’s basically script that defines the data range first (StartX, StartY) (2, 5) to (MaxX, MaxY) (10, 18).Then it carries out a find and replace to insert the shapes and formats where required.

clean4

The portfolio and .qes file containing the tab template shown above can be downloaded here. The end result is as follows:

clean1

 


 Aggregated scripts

In basic terms, aggregated scripts are a way of retrieving aggregated information e.g. a mean or median. So you can now create coded variables from this point like: those above mean / those below mean and this variable won’t require additional work when new data is added to the .qes file (and the mean changes).

The example .qes file can be downloaded here. Take a look at variable avg#3. We are able to display the average time in the correct format by first working out the mean of Q4a. We use Q4a.data.mean() (17.73) to do this. In the second line we work out the mean with no decimal places (17). In the third line we work out the difference 0.73 and re-factor it be between 0 – 60 (44). Then, finally, we insert these numbers into the text we want to display: “Average Time – [17:44]”

as1

The above example shows aggregated scripts for use in created variables but they can also be used in the cleaning script and calculation arithmetic script modes. The latter is demonstrated in the example portfolio in tab definition: Average Time – Method 1. Here there is the calculation: Average Time which performs a similar format adjustment on our mean for Q4a.
 


Table arithmetic (Calculation arithmetic)

In the example .qes file and portfolio which can be downloaded here, open the tab definition: 2.TA_Calc_Arithmetic. 

Here you will see a 10 point rating scale for 10 brands. The aim is to create a simple calculation:

100 * sum of (count x rating) for one brand / sum of (count x rating) for all brands

So for the first brand it would be: 100 * (182) / total of all entries in the ‘Sum’ row (1498) = 12.15

ta2

When using calculation arithmetic we think of every cell in the table as having x & y co-ordinates e.g. the top left cell has co-ordinates (1,1)

We define our range of cells we want to sum across:

j = CurrentTable.startX to CurrentTable.maxX

Where startX is the first column which contains data (3) and maxX is the last column (12) now we sum up all the values contained in these cells on the 12th row (Sum) using the following syntax:

i = i + CurrentTable.getcell(j,12).value

 Note, here you can replace the y co-ordinate of 12 with:  CurrentTable.maxY – 1  – this also means the 12th row but will automatically look at the 13th row if one more rating is added to the scale.

Now that we have our ‘total of sums’ we divide the sum calculation, Calc(1), by this to get our desired result using: return (Calc(1) / i) * 100

You may have noticed that we now use Calc(1) instead of the calculation reference we used previously {1}. This is necessary for adding the new scripting language in this calculation type. References previously saved as {n} here will be automatically updated to Calc( n ).


Table suppression

For the first time in Analyse, we have the ability to fully suppress tables from the output if the table base is below a certain number. You have the flexibility to set this threshold in the same way as you can for setting row / column / edge suppression:

bts1

The usual requirement is blank table suppression which removes empty tables from outputs. In this case you would of course set ‘if base <=’ to 0
 


Paste captions

A new option, Paste captions, has been added to the context menu when you are working in the row / columns / edges of your tab definitions. If you’ve ever had to make a large number of text changes to variables or code captions in the tab definition, you’ll know it would have taken time to paste/write them in to each of these elements individually.

Now you can create your updated text in Word or Excel, for example, and paste captions in wholesale on to your variables or codes to save a lot of time when faced with this sort of exercise.

pc1
 


New keywords in script calculations.

You can now use RowQuestion, RowSubQuestion, ColQuestion, ColSubQuestion in calculations by script

You may be aware how to use script calculations in Analyse:

kw1

If not, there is a fairly informative article here which steps through some usage examples. There is another article here which concentrates on scripts used to create mean summary tables.

Basically, it’s a script stored in a calculation which allows you to access or filter your results by a question which is not in your tab definition.

The example files are here. Open up ‘6.AS_Keywords_Portfolio.xml’ and in the tab definition there is a demonstration of this in the calculation: ‘n (q4)’. The script here is  ??q4?? Has {1;2}

This filters the counts in our table by those who answered ‘Excellent’ or ‘Very good’ at q4.

This is a question specific script. It means that should we be required to apply this for the same table set-up but different questions then the calculation would not work. e.g. loop1 (replaced with loop2) and q4 (replaced with q5). In Analyse 5.3.5.0 we have introduced some new keywords to circumvent this inflexibility.

Take a look at the calculation ‘n (Generic)’. The script here is: RowSubQuestion Has {1;2}

kw2

The results here are the same as those given by ‘n (q4)’ but, of course, now allow flexibility to use this tab template definition across different loops / variables.
 


New options in level

There are two new options added to the ‘Level’ drop-down box in the tab template:

rl_cl_options

The aim here is much the same as in the previous section, to reduce the number of tab templates we need to create.

An example is when you create a summary table (let’s say for loop1) and want to show figures for the response level rather than the respondent level. We set the level here to loop1 and save the tab template. Previously we couldn’t use the same tab template for the summary table for, let’s say, loop2 but now we can using these options.

The new keywords in script calculations and these level options add a great new level of efficiency for tab template management.

Version 5.3.4.0: askiaanalyse

This post is the second in a series of two that detail the key features in version 5.3.4.0 of askiadesign & askiaanalyse.

Much development work has been done in 5.3.4.0 which bring about a whole host of great new features. A detailed list of these can be found in the version roadmap. Below are five of these features.


Table of contents:

    1. Improvement of inverted data format.
    2. Nested Edges.
    3. Sig Test Options Stored In Variable / Column.
    4. Excel Export Options.
    5. Weighting Efficiency.

 


Improvement of inverted data format

Inverted data is stored and read variable by variable rather than by respondent. This generally speeds up processes such as downloading, expor ting, importing and recalculating. It is another data format which stores data in a .dat folder rather than in just a .qes file.

Inverted data format options

The ‘Re-invert database’ option in Askia Analyse is used to invert the data and the ‘Open an inverted survey’ option is used to access this data format in Askia Tools.

In Analyse 5.3.4.0 a number of improvements have been made to this format:

  • We have decided to rename the old files and not use the number of responses as an extension – this was causing unnecessary problems when a question was recalculated or if the max number of responses was manually changed in Design. The extension of the inverted data files  is always .dat.
  • The developed questions in a loop are no longer stored individually – the grayed questions always contained the information so we thought the cost of reading the whole grayed data for that question was a small price to pay compared to store all the data twice. This significantly decreases the number of files and lets you easily change your mind about the “Develop level” option in Design.
  • We store the system data – or peri-data – such as start time, end-time, IP-address, completion, …
  • The data is compressed which can gain up to 95% diminution of file size ( versions prior to 5.3.4.0 were a simple uncompressed copy of the memory)
  • We have backwards compatibility: inverted data produced with a version prior to 5.3.4.0 is read properly in Analyse. The new inverted files are readable by Vista but not by older versions of Analyse or Tools.

In most tests we have seen 85-95% decrease of the inverted database size and no noticeable deterioration in the reading speed. For example, in the last test, I reduced the size of a .dat folder from 4.2 GB to 45.0 MB. In order to convert from the old to the new format you can use the following steps:

  1. Open the old format inverted data in Askia Analyse 5.3.4.0 version or higher.
  2. File > Export a sub-population
  3. Select the new target file > select ‘All interviews’ as the sub-population > check ‘Export as inverted database’. At this stage you can also select any calculated variables to export or that can be done after by copying / importing the variables from one file to another.

 


Nested Edges

Prior to Analyse 5.3.4.0, the variables you place in your edge would be line up side by side in your edge banner. So, for example, if I have three variables in my edge with 2, 3 and 4 categories then I would have a single edge banner of 9 categories.

From 5.3.4.0 onwards you have the option to change this so that your edges build upwards and you can have two or more variables (edge banners) layered on top of each other. The result from the example above is that you have 2 x 3 x 4 = 24 crossed categories created.

The benefit of Nested edges is that they allow you to have many crossed variables / dimensions in your tables. Previously you would be limited to three before you had to start thinking about using scripts, crossed calculated variables or sub-populations.

Without setting:

Edges in askiaanalyse

Settings for nested edges in askiaanalyse

With setting: – order of nested edges depends on order of variables in Edge

Cross-tab with 2 nested edges in askiaanalyse

You can keep layering them up e.g. if we add another variable, ‘Agreement’, into our edges:

Multiple nested edges in askiaanalyse

We get the following:

Cross-tab with 3 nested edges in askiaanalyse

It’s worth noting that you cannot have a hybrid situation where you have some edges layered and some not. You will have to manage this using your columns as well as your edges.

Example of usage

 


Sig Test Options Stored In Variable

Up to now, it was only possible to store col sig options in the tab template. Therefore, the same tab template would need to be replicated for small tweaks in the testing. The purpose of this new feature is to enable more flexibility by storing the col sig options in the column profile and by doing so reduces the number of tab templates required.

The closest relation we have to this new feature in versions prior to 5.3.4.0 is ‘Specify columns’.

Specify test columns for column significativity

The only difference with the latest option is that the Test cols test is not entered into the advanced options (above left) but instead the column profile by right clicking in the columns and selecting ‘Col-sig testing’ (below).

Specify test columns in column profile

Since these options can be stored in the columns, they will also be saved in a profile or a portfolio.

Example of usage

 


Excel Export Options

Prior to Analyse 5.3.4.0, we had the set of options (A) below. Now since 5.3.4.0 we have set of options (B) which allow more flexibility in organising your Excel tabulations.

Excel export options

The following is a description of what these additional options do:

New sheet for each portfolio chapter

When you are in the portfolio view you can right-click > Insert a chapter. This has the use of keeping large portfolios tidy by organising the tab definitions into sections. With the ‘New sheet for each portfolio chapter’ option set you can now export each of these chapter sections to its own sheet in Excel. So the below will give you 2 sheets. Sheet 1 has 16 separate tables and sheet 2 has 10 separate tables.

New sheet for Portfolio chapter in askiaanalyse

New sheet for each tab definition

A tab definition is created in a portfolio every time you press the yellow folder with green arrow icon in the view below:

New sheet for each tab definition in askiaanalyse

In the example below we have created 3 tab definitions. The shown settings will output 3 sheets in Excel. Sheet 1 has 8 separate tables, sheet 2 has 8 separate tables and sheet 3 has 10.

New sheet for each table definition in export to Excel options

New sheet for each edge

We have 5 variables in the rows and four responses in the edge. Our settings dictate that we therefore have 5 x 4 tables.

With the old settings we could select:

‘One tab per sheet’ – Yes, which would give us 20 sheets in our Excel output or

‘One tab per sheet’ – No, which would give us 1 sheet in our Excel output.

One tab for every response in edge option in askiaanalyse

Now with the following settings we can create an Excel output which has 4 sheets, one for each edge response. Each of the 4 sheets contains 5 separate tables, one for each variable in the rows.

New sheet for each edge option in askiaanalyse

It’s worth noting here if you were to also set ‘One tab per sheet’ – Yes, and rerun your tables, the output would be 20 sheets. This setting overrides the others. Furthermore, if you use the three settings in conjunction with each other, the setting which produces the greater number of tables will take priority.

 


Weighting Efficiency

The weighting efficiency is a measure of how much skewing we have had to do in order to get the weights to converge – the result is a percentage. The closer it is to 100% the less skewing.

In 5.3.4.0. onwards, when you run a weighted set of tables, a file called “Report of weights.txt” is created in the .dat folder that belongs to the .qes file you have opened in Analyse. If the .dat folder doesn’t already exist, it will be created.

An explanation of the weighting efficiency formula can be found here.

Reviewing the attached WeightingEfficiency.xlsx file should also help to understand how we arrive at the weighting efficiency figure.

This looks at the 24 interviews we have in the Data.qes and for each interview lists the weighting factors in column E. In the range L2:U36 it works out, step by step, the numbers required for eventually arriving at the weighting efficiency of % 80.05722937.

Weighting efficiency in askiaanalyse

In WeightingEfficiency.rar there is a .qes and weighted portfolio. If you open these and run the results, you should see the following in the Report of weights.txt created in the .dat folder:

Weighting efficiency report in askiaanalyse

The weighting info on the first line relates to the weighting options you have set:

-Min weight-            -Max weight-            -Number of possible iterations-         -Accuracy-

Weighting options in askiaanalyse

The maximum weight displayed in this file is different to what you’ll see in the weighting options because the base calculated by summing the weighting factors (24.82096438) is different to the unweighted base (24).

If you interview 100 people, and you set your base to be 10,000,000, a “normal” interview would have a weight of 10,000

If you set the maximum weight to 5, it means the algorithm will ensure the weight will not allocate a weight 5 times more than a normal interview. In this particular example, it means it will keep all interviews’ weights under 50,000.

Significance and Count Threshold

Why does significance change when I switch level or add waves of data in Askia Analyse?

This post explains which count is considered for the ‘Count threshold’ setting in Col sig advanced options. There is detail on how to calculate ‘Counts when independent’ and why this can change sig testing when the total base grows.


From time to time clients will raise a query regarding sig testing (Column significativity on closed) for a particular cell changing when the total base of their table grows, even though the count and % for cells in the table remains the same. E.g. this can happen when new waves of data are added or the level has been changed to show the response counts rather than respondent counts.

The reason for this is almost certainly the Count threshold setting in the col sig advanced options; it has been left as the default value, 5.

Column significativity advanced options in askiaanalyse

The Count threshold does not use the counts you would normally see in your tables but, instead, it uses the counts from the calculation Counts when independent.

You need to use the count when independent rather than the actual count because the usual count in the cell (crossed count) can still carry importance at low or zero counts.

Below is an example of when the the sig testing changes even though the count and % have remained the same (see column G)

Example of sig test change in askiaanalyse

5 is the default because this doesn’t bring to your attention differences which are not statistically important. The side effect is that you can have changes as the total base grows over time (and hence changes the count when independent). If this behaviour is not in line with requirements, the Count threshold can be changed to 0.

This applies to Column significativity on closed but you cannot perform the same calculation for Column significativity on numeric. The Count threshold setting exists in its advanced settings but it is not applicable and has no effect.

Link to this knowledge base article in our help centre