Feedback from that session was that this is a very helpful feature, but not everyone has access to Server, so how else can you see how Alteryx is being used?
For this blog, I am going to cover two approaches:
1) Tool usageThis is a hidden example built into Designer, it is a macro which searches through the .yxmd/yxmc files (these are just xml text files) on a user’s machine to identify which tools are being used within a workflow.
To access the macro, in Designer go to [ ] and open up the example workflow. Once you are in the example workflow, it’s just a case of selecting the folder where the Alteryx workflow files are saved and running the workflow. The output of this macro will give you details on the tool category, tool name, and the workflow name.
From here you can do some further analysis such as filtering out the standard macros which come with the Alteryx install, get a total count of workflows a user has built, the tool categories a user focuses on etc. Running this now on my machine I have learnt that I have built over 2,000 workflows, that my favourite tool is the formula tool with over 15,000 uses of it and that I have built over 100 macros!
In addition to getting tool usage stats, I have also found this tool really useful to locate that workflow where a particular tool has been used. For example, I had a colleague who wanted to know examples of when a particular tool could be used (in this example it was the map input tool). Now it would be pretty hard to put your hands on the workflow straight away that used that particular tool, but by running the macro you can then filter (it’s great that filtering in the browse pane is now possible!) to that tool, find the workflow name and load it up!
If your organisation has users save their workflows on a network drive, point the macro to that network drive then away you go. One limitation of the example workflow straight out the box is that while you will get details about the tools being used, you won’t know who built them. This can be solved though (if your users are following good governance) as the workflow has meta info about the author, which like details of the tools is embedded in the xml, so this just needs parsing our as well.
When collecting this information, it can provide useful insights into the workflows being built by users, and from a tech enablement perspective it can help identify which tool categories each user uses a lot and then you can provide advanced training on the tools, or identify areas where you can introduce other parts of the Alteryx palette.
2) A hidden macro within a workflowThe first example is great to get a lot of information about the tools being used, however to get the specific tool usage by user it relies on the population of user details within the workflow metadata configuration pane.
In addition you get details of the individual workflows being produced, but no information about the frequency of use. For example if there is a macro which makes use of an API, the first approach will give you details that a user has a workflow called, for example, ‘External Provider API.yxmc’, but there is no way to collect how frequently they may be using the external provider’s API. This is where the second approach has it’s benefits.
The second approach is to create a macro (I do it this way as it is then easy to embed into a workflow or another macro), which leverages the ‘Who Am I’ feature in Windows Command Prompt to identify the user, Workflow Constants to get information on the workflow name and the DateTimeNow tool to get a time stamp.
The run command tool is used to capture the user details from their windows login, so it’s helpful if this is a unique identifier such as a Staff ID or email address (set up below).
This workflow then writes out the information collected at the time of the workflow run to an Excel file (as you can append new data to an existing file), but this could quite easily be to a database or another file type.
So this blog sets out two ways in which either you as a user or an organisation can use tools available directly within Alteryx Designer to monitor usage of Alteryx and understand how your team are making use of Alteryx.
The techniques here do not require the Alteryx Server to capture this information, however the approach here has limitations such as having users save their workflows to a location that you can access, and ensuring that they embed the macro from the second approach into their workflow. Whereas the Server based approach is able to capture much more meta information and not rely on these factors which make it a richer dataset for understanding usage.