While the built-in system variables described above are read-only, you can create and modify your own set of user variables. You can base their values on built-in system variables or other data about the request's context, then transform them as described in the Modify a variable section.

Global variables in properties

First you need to declare the variable within the default rule's variables array, otherwise you get an error when you later try to assign to them or invoke them in option values. The example below defines a single variable whose unique underlying name is VAR_NAME. Variable names may only feature alphanumeric and underscore characters. Uppercase is recommended by convention but is optional.

{
    "rules": {
        "name": "default",
        "criteriaMustSatisfy": "all",
        "options": {
            "is_secure": false
        },
        "variables": [
            {
                "name": "PMUSER_VAR_NAME",
                "value": "default value",
                "description": "This is a sample global variable.",
                "hidden": false,
                "sensitive": false
            }
        ],
        "criteria": [],
        "behaviors": [],
        "children": []
    }
}

There are two different ways variable names appear:

• When you declare a variable in the default rule's variables array, modify a variable with setVariable, or match it with matchVariable, you add a PMUSER_ prefix to refer to the variable name as PMUSER_VAR_NAME. Though not mandatory, you should prefix variables as best practice to align with the convention Property Manager enforces in ​Control Center​. In activated metadata, variables appear in the array as %(PMUSER_VAR_NAME).

• When you insert a variable as an expression within behavior and criteria option fields, you need an additional user. namespace prefix: {{user.PMUSER_VAR_NAME}}.

Local variables in includes

The same principles apply to includes. However, note that includes differentiate between global variables that are inherited from the parent properties, and local variables that only work on the include level.

There are different ways variable names appear in includes:

• When you declare a local variable in the default rule's variables array, modify a local variable with setVariable, or match it with matchVariable, you add a prefix that features the include ID and the variable name: PMINC<includeId>_VAR_NAME. To obtain the includeId prefix for the local variables, create or clone an include first.

       "variables": [
           {
               "name": "PMINC1234_EXAMPLE",
               "value": "Value of Local EXAMPLE",
               "description": "This is a sample local variable.",
               "hidden": false,
               "sensitive": false
           }
       ],

• When you insert a global variable as an expression within include's behavior and criteria option fields, you need an additional parent. namespace prefix: {{parent.PMUSER_VAR_NAME}}. This also applies if you want to modify a global variable with setVariable or match it with matchVariable.

• When you insert a local variable as an expression within include's behavior and criteria option fields, you need an additional user. namespace prefix: {{user.PMINC<includeId>_VAR_NAME}}.

       "behaviors": [
           {
               "name": "constructResponse",
               "options": {
                   "enabled": true,
                   "responseCode": 200,
                   "body": "fixedstring{{user.PMINC1234_EXAMPLE}}{{parent.PMUSER_EXAMPLE}}",
                   "forceEviction": false,
                   "ignorePurge": true
               }
           }
       ],