Experimental Features¶
The experimental features section section contains specific options requested by Roistat clients. These options are not available in the general settings of Roistat features.
To open the experimental features section, in the Roistat project go to Settings → Additional → Experimental:
Please note:
To use experimental features, you must be the project owner or have access to manage experimental features.
Calltracking¶
Create deals on call even if a created client exists in CRM¶
By default, deals based on calls are created for new customers only.
If you enable this option, Roistat will start creating deals based on calls from numbers that are already in the CRM contact list.
The contacts in the proxy lead data are checked.
Do not create deals after phone call¶
Even if automatic creation of deals by calls is enabled in the script, this setting will disable it.
Create deals via calltracking even if there are deals in "In work" status group¶
Roistat does not create a new deal in CRM for a call passing through Roistat Calltracking if there is already a deal in CRM based on a call from the same number, and this deal is in the status from the In Progress group. If this option is enabled, Roistat will create deals based on calls passing through Roistat Calltracking, even if CRM contains deals in the In Progress status based on calls from these numbers.
Send Roistat SIP account address instead of dialed number in INVITE requests when Roistat SIP is enabled¶
If this option is enabled, the INVITE request, which invites the user to participate in a communication session, sends the address of the Roistat SIP account instead of the dialed number.
Disable call playback by reference to CRM without account with access to the project in Roistat¶
There is a link in the deal in CRM where you can listen to the call. If this option is enabled, listening to calls from a link in a CRM deal is not possible without an account with access to the Roistat project.
Do not send call recording to CRM¶
Roistat sends a call record to the connected CRM along with the deal created based on the call. If this option is enabled, Roistat will not send a call record to the connected CRM.
Do not record phone calls¶
Roistat automatically records phone calls passing through Roistat Calltracking. Disable this option so that calls are not recorded.
Don't normalize the caller's phone number in processing calltracking calls¶
When processing Calltracking calls, Roistat normalizes caller numbers for sending to CRM in a single format. If this option is enabled, Roistat will not normalize numbers.
Don't normalize the dialed phone number in processing calltracking calls¶
Roistat normalizes the dialed number when processing Calltracking calls so that all numbers are in the same format when being checked and transferred to CRM. If this option is enabled, Roistat will not normalize numbers. This feature can be useful when the visit number is already transferred from a third-party service along with the call information, and the dialed number is a SIP address or it does not need to be normalized for other reasons.
Do not send a comment when creating a transaction in the CRM via Calltracking¶
If this option is enabled, comments on deals from Calltracking will not be created. In the proxy lead, the field of the deal from Calltracking will be empty.
Do not send analytical data to a third-party PBX for call tracking¶
When forwarding a call, Roistat will not send the visit number, source and replacement number to the third party PBX (via SIP headers). Use this option if you need to restrict data transfer when using a third-party call center.
Don't remember the advertising channel for repeated calls¶
This feature will be useful if a replacement number that was previously used in the Calltracking Script A was tied to the new Script B. If you enable this option, repeated calls to this number will be assigned an advertising channel corresponding to the Script B.
Example: a client went from a Google Ads ad to a website, saw the number from the Script A, and called. A few days later, he called that number again when the number was already used in the Script B. If this options is enabled, the source of the second call will be redefined.
The deal status does not affect the repeated call source. Even if the deal based on on the first call is closed at the time of the next call, the next call will be assigned the source of the first call. Turn on this option if you want the source to be redefined.
The country code that will be used to normalize phone numbers¶
If the phone number being normalized is suitable for several countries, the country code selected in the settings will be used.
Email to send notifications about missed calls (separate several email addresses with comma)¶
Roistat sends emails about missed calls passing through Calltracking to the specified email addresses. Calls are considered missed if:
- The client did not wait for an answer and hung up;
- The call was dropped;
- The number was busy.
Email to send notifications about failures during calls (separate several email addresses with comma)¶
Roistat sends emails about failures in calls passing through Calltracking to the specified email addresses. Any call other than received and missed is considered a failure.
Timeout of Calltracking widget window closing for Manager in Chrome (in seconds)¶
The period in seconds after which the widget window for incoming calls in Google Chrome closes.
Minimum time of conversation, after which the call is considered as answered (in seconds)¶
You can specify the time in seconds that Roistat will take into account when determining the call status.
Example:
As soon as the call is established, the answering machine is activated. The system considers the call accepted, even if the manager did not have time to answer. You can specify how long the answering machine will last (for example, 10 seconds). Thus, when a call is established, the system will not consider the call accepted for another 10 seconds.
Please note:
If the call duration was less than specified in this option, a deal will still be created based on this call, since it is created at the beginning of the call and is not tied to its status.
AutoCorrect rules of the dialed number in the Calltracking¶
Enable this option if your equipment does not accept letters as the called party. Example: when using the Roistat SIP user, if you specify roistat123_1=1231, the forwarding will be performed with the transfer of SIP 1231. You must specify a value in the following format: key1=value1,key2=value2
.
Redefining call forwarding numbers of the scenario for swapped numbers¶
The setting allows you to forward calls to a number that differs from the one specified in the script. Enter a value in the following format: "replacement number 1"="forward number 1", "replacement number 2"="forward number 2"
. For example: 74951111111=74992222222, 74953333333=74994444444
.
Name of the field with the phone number in the deal or contact in the CRM, which should be used to identify source of the deal when using Roistat Calltracking¶
This experimental feature works for both static and dynamic call tracking scripts.
Examples of issues that can be solved by enabling this option
- You have configured the integration of third-party telephony with your CRM, and calls are uploaded via API. You want to use Roistat Calltracking to identify call sources.
- You have configured the integration with a third-party call tracking service that does not support linking the visit source.
How it works
When uploading a deal without a visit number to the project, Roistat checks calls in the project with the same phone number made within +/- 1 hour from the moment the deal was created (for example, if the deal was created in 10:00, Roistat will check calls from 9:00 to 11:00). If such a call is found, the deal is assigned a visit number from the information about this call.
If you specify the name of the CRM field where the date of the call is stored, when loading a deal without a visit number into the project, Roistat will check calls in the project with the same phone number made a few minutes before the date from the deal field. If there are several such calls, the deal is assigned a visit number from the information about the call that is closest in time.
For the experimental feature to work, it is required to specify not field IDs, but their names from CRM (for example, calltracking_phone, roistat_phone, and so on). Contact fields are prefixed with client_, for example, client_phone_number. If you want your standard (system) phone field to be used, specify phone as the name. The phone field must contain the customer's number in the format that is stored in the Call History.
If, when searching for calls, you want to take into account not the date of the deal creation, but the date of the call, specify the deal (or contact) field in CRM with the date of the call as the second parameter (separated by a comma). For example: phone_number,date_call_creation
. The date of the call must be passed in the following format: yyyy-mm-ddthh-mm-ssz
.
Please note:
-
If the roistat field is filled in when loading a deal from CRM (or an additional field specified in the option called The name of the field from which you want to get the lead source if roistat field is empty), it will be a priority for determining the source of a deal based on a call in Analytics.
-
If the call source must be prioritized over the roistat field in CRM in order to determine the source of the deal, enable the option called Make the call source take precedence over the deal source in CRM.
-
Если для определения источника сделки источник звонка должен быть в приоритете над полем roistat в CRM, то включите ЭВ Make the call source a priority than the deal source in CRM.
The specified field works only with uploaded leads.
Backup numbers (or SIP) for call forwarding in Calltracking¶
Calls to the specified backup numbers will be received if Roistat could not reach the main number specified in the script, or the number was busy.
You can specify one number for all scripts, or different numbers for different scripts. Only one number can be assigned to one script. In this case, the same number can be used in different scripts.
-
To assign one backup number to all scripts, simply enter this number in the 7xxxxxxxxxx format (no symbols or spaces).
-
To add a backup number to a specific script, use the formula phone number=scenario number, for example: 74951234567=1. The script number can be seen in the script settings to the right of its name.
-
To assign one number to several scripts, use the same formula, listing script numbers separated by commas: 74951234567=1.2.
-
If there are several backup numbers, each formula must be placed on a separate line.
ID's of scenarios for which you want to transfer the dialed number instead of the caller's number when forwarding¶
If you want to process the number the client is calling instead of the client number, specify the script numbers separated by commas. When this option is enabled, a contact or deal will be created with the customer's phone number. The option only affects the number display on the PBX side.
Time to wait for a response in seconds until the call will be forwarded to the backup number (or SIP)¶
Use this setting if, for example, you need to forward a call when the manager did not answer in time.
Additional SIP-headers for calls forwarding to external pbx¶
The setting allows you to process additional marketing information about the visit on the PBX side, for example, the client's city. Enter a value in the following format: script number:header name={header value}
; script number:header name 2={header value 2}
. For example: 1:my-city={city}
; 2:my-domain={domain}
.
Special masks for certain substitution numbers¶
If you want to display certain numbers on your website in a format that differs from the general mask specified in the Calltracking script settings, specify the "phone number = mask" match in the following format: number as specified in the script=desired number mask
. You can specify multiple matches separated by commas. For example, 7495123456=8495123456, 7495120000=84951288888
.
Make the call source a priority than the deal source in CRM¶
Allows you to prioritize the source of the call passing through Calltracking over the source of the deal in CRM.
This option works only if the Name of the field with the phone number in the deal or contact in the CRM, which should be used to identify source of the deal when using Roistat Calltracking option is enabled.
Integrations¶
Do not send information on marketing channel in CRM when creating deals via proxy-lead mechanism¶
If this option is enabled, Roistat will not send information about the landing page referral source to the deal in CRM if the deal information is transferred to CRM via Roistat.
Do not normalize client numbers loaded from CRM¶
It works in the same way as the option Do not normalize phone numbers from Lead Catcher, but for uploaded contacts (Client Management tool).
Do not normalize phone numbers sending via Proxyleads¶
Use this option to send the number to CRM in the format received by the proxy lead. The option works when creating leads through integration with Facebook Lead Ads, from site forms, through Calltracking and using code (leads/add method).
Do not cut html-tags while sending leads to CRM¶
When this option is enabled, Roistat does not remove HTML tags from lead data. This will allow you to customize "layout" in CRM: for example, pass clickable links to comments or set up line wrapping.
Please note:
After enabling this option, the built-in protection against XSS attacks will stop working.
Check for duplicates only for deals in CRM, without taking into account proxyleads¶
If this option is enabled, Roistat will check leads for duplicates only for sent proxy leads.
Please note:
In this case, a task/note for the deal will not be created, since checking leads for duplicates does not involve CRM data.
Do not account the leads loaded from CRM and only check duplicates of sent Proxyleads¶
Enable this option if your CRM does not return correct information about the creation of a new lead received from Roistat. In this case, repeated requests to create a deal will not be sent to CRM.
Match the source of the visit with the deals using own logic of creating leads¶
Use this option if you want to keep the current logic of creating leads in CRM. Uploaded deals will be linked in analytics with the visit number received from Roistat.
Please note:
The source of the visit is associated with the deal only if the visit number was received within +/- 1 hour from the moment the deal was created.
For example, if the visit number was received at 12:00, it will be associated with deals created between 11:00 and 13:00.
Specify the time zone of deals loaded from CRM¶
Use this option if the time zones in CRM and in the Roistat project are different.
Select the time zone to which the deals in CRM belong. For example, specify the UTC+3 time zone for deals created in Moscow, UTC+0 for deals created in London, and UTC-5 for deals created in New York.
An example of how the option works
The time zone of the Roistat account is UTC+3 Moscow, and this option specifies the time zone UTC-8 Los Angeles. A deal created in CRM at 00:58 has been uploaded to Roistat. Roistat considers that all deals are loaded in the UTC-8 time zone, and in the analytics brings them to the project time zone: UTC+3. Thus, in Roistat, 11:58 a.m. will be considered as the time of the deal creation.
Lower date of order creation¶
Specify the deal creation date (in the YYYY-MM-DD format), starting from which deals should be loaded into the project. Use this option if you want to upload deals that were made in the current integration before the date the integration with Roistat was created.
Orders older than this date will not be loaded into the project. By default, the minimum deal creation date is equal to the CRM integration activation date.
The phone number format to be sent to the CRM via Roistat¶
Use a mask where the numbers must be replaced with the X letter. For example: 8 (XXX) XXX-XX-XX
or +7XXXXXXXXXX
.
Data anonymization¶
This experimental feature allows you to download a client without contact information. The name, phone and email of the client are hidden. To enable this feature, please contact Roistat support. Once data anonymization is enabled, you will no longer be able to use Marketing Automation. In Client Management, only client IDs will be displayed.
The field name of the deal in CRM if you want to load the city information from this field¶
If you want to manually send information about the city in uploaded leads, specify the field that will contain information about the city.
The field name of the deal in CRM if you want to load the region information from this field¶
If you want to manually send information about the region in uploaded leads, specify the field that will contain information about the region.
The name of the CRM field which must be used to receive data on the domain and landing page for leads without a visit number¶
Specify the field you want to use for uploading information about the domain and landing page for leads without a visit number.
Please note:
-
Use the following domain format: site.com.
-
Leads with a domain obtained through this option must be in the string containing the domain.
Prioritize the CRM field data over the domain and landing page from the visit data¶
Enable this setting if you want to prioritize the data from the CRM field specified in the The name of the CRM field which must be used to receive data on the domain and landing page for leads without a visit number option, even if a domain and landing page were defined in the visit.
Advanced filter settings to load deals from CRM¶
Add a filter in JSON format if you need to set complex conditions for filtering deals when loading them into a project.
- Allowed operators: ">", "<", "<=", ">=", "=", "!=", "in", "not_in", "or", "and", "like" , "like%", "not_like", "not_like%", "null"
- The filter looks like this:
["Field", "Operator", "Value"]
- For
in
andnot_in
operators, the value must be an array, that is, must be enclosed in[]
. - For all other operators, the value cannot be an array.
- For the
null
operator, the allowed value is 0 and 1.
Filter example:
[{
"field":"Sales funnel",
"operator":"in",
"value":[
"Resale",
"Events",
"Promo",
"Black list",
"Test funnel"
]
}]
You can also apply multiple filters with a logical operator:
{
"and":[
{
"field":"Sales funnel",
"operator":"in",
"value":[
"Resale",
"Events",
"Promo",
"Black",
"Black list",
"Test funnel"
]
},
{
"field":"date",
"operator":"<",
"value":"2021-05-07T21:00:00"
}
]
}
This experimental feature can be used simultaneously with the Deal filtering option in the CRM integration settings. In this case, the filter from the experimental feature is applied first. After that, if the deal matches the conditions of the first filter, the filter from the integration settings is applied.
The name of the field from which you want to load the lead source if roistat field is empty¶
If the roistat field is empty and the lead source is stored in another field, specify the name of this field to track leads in analytics. This field must be optional, not standard.
The field name is converted to lower case when uploading to Analytics. For example, the CRM field "SOURCE" will turn into "source" in Roistat Analytics.
You cannot specify multiple field names.
The name of the field from which you want to get link to deal in CRM¶
Enable this setting if you want to rewrite links to deals by using values from an additional field in CRM. Specify the name of the deal field in which the link to the deal is transmitted.
The name of the field from which you want to load the sales date¶
If the date of sale is set in a custom way and is contained in a specific CRM field, specify this field. If this field is empty, the sale date will be set according to our standard algorithm.
The date must be in one of the following formats:
- YYYY-MM-DD
- DD-MM-YYYY
- DD.MM.YYYY
- Timestamp
The field names from your CRM that do not need to load to Roistat¶
If the CRM contains confidential information that should not be uploaded to the project, specify the required fields separated by commas.
Webhook url for acquisition of a lead in Roistat¶
The format of the webhook that will be sent to the address:
{
"id": "198",
"title": "Caught lead: Alex, +7(313)111-11-13",
"text": "Form data: Alex, +7(313)111-11-13\nPromo code: 3217\nChannel: Direct visits\nLanding page: https://test.com/Contacts/\nReferrer: \n",
"name": "Alex",
"phone": "73131111113",
"email": "",
"data": "{\"source\":\"organic\",\"sourceLevel1\":\"organic\"}",
"contact_data": "[]",
"visit_id": "3217",
"date_create": "2019-05-13 13:49:14"
}
Enter the name of the field from which you want to take the date of creation¶
Specify the name of the CRM field from which you want to upload the deal creation date. You can also specify a field ID. You can specify multiple fields separated by commas. If the field is empty, the deal creation date will be loaded from the standard CRM field.
- The date and time uploaded from the specified field is used for matching.
- When filling in the field, you can use the following formats: YYYY-MM-DD or DD.MM.YYYY.
Always create a new client¶
By default, when creating a new contact in CRM, Roistat checks for duplicates, that is, for similar contact details: phone and email. If the contact details match, a new contact is not created, and the deal is linked to an existing contact. Enable this option if you want to always create a new contact. For this experimental feature to work, check for duplicates must be disabled.
Do not send to site the information about active in the project Yandex.Metrika counters¶
If you want to hide the connection between your sites, enable this setting so that related Yandex.Metrica counters are not displayed at the site level. In this case, Roistat will not be able to show search phrases in Rates Management.
Do not get the source from the deal comment in CRM¶
If you want Roistat not to receive the source from the deal comment in CRM, enable this option. By default, if there is no roistat field in CRM, Roistat gets the source from the deal comment.
Values of the roistat field from your CRM that do not need to load to Roistat¶
Specify the values of the roistat field in CRM that you want to ignore when uploading to Roistat (you can specify multiple values separated by commas). These values will not be used to determine the lead source in Analytics.
Working time of deals import¶
Use this option if you want to upload deals from CRM at a certain time interval. Specify an interval in the 0-23
format (UTC+0) to set the start time for importing deals. For example, if you specify the 0-8
interval, the loading of deals will be launched only in the interval from 00:00 to 08:00 UTC. The rest of the time deals will not be loaded into the project.
Interval of source determination when matching a deal and proxylide¶
You can specify the time in the 1d1h1m1s
format. For example, to set the interval to 1 hour 30 minutes, enter 1h30m
. When determining the deal source using matching, this time period will be considered the maximum possible difference between the time in the proxy lead and the time the deal was created. This can be useful in cases where the time in the proxy lead and the time the deal was created in CRM differ by more than 1 hour, so the source is not determined or is determined incorrectly.
Send to the Webhook address also information about a new application, which is recorded in Roistat, but not transferred to the CRM¶
The option allows you to send information about a new lead to the Webhook address, which is stored in Roistat, but not transferred to CRM (in the list of sent leads, such requests are marked Do not send).
Consider the comment field in the standard duplicate check logic¶
Enable this option so that the standard check for duplicates includes checking the Comment field for a full match (in addition to checking the lead title, client name, email, phone, visit number and additional fields).
Allow filtering by the roistat field when loading orders¶
This option allows you to filter deals by the roistat field. Filtering is configured in the advanced settings of the CRM integration.
Overwrite order history via API¶
Enable this option to completely overwrite the order history during import. By default, the history is simply updated.
Consider the cost of goods when calculating the deal cost¶
Enable this option to have the cost of goods taken into account when calculating the cost of the deal. The cost of goods is taken into account only if the cost of the deal is not specified.
Do not lowercase the roistat field when importing deals¶
If you enable this option, the roistat field will not be reduced to lower case when importing deals. By default, if the value like HELLO_WORLD is passed in the roistat field, it will look like hello_world in the analytics.
Check for duplicates only for deals in CRM, without taking into account proxyleads¶
By default, a check for duplicates also includes proxy leads data (data arrays that are transferred to Roistat and stored in the list of sent leads). Enable this setting so that proxy lead data is not taken into account when checking for duplicates.
This can be useful if in one project leads are created both through Roistat and using matching. If you enable this feature, leads that were included in the proxy lead but were not sent to CRM will not be checked for duplicates.
Transfer the roistat visit from the first client's deal to subsequent ones¶
Use this option to have the visit number from the client's first deal transferred to subsequent deals of this client that do not have a visit number (the roistat field is empty).
For example, you can link online and offline deals of the same client:
-
The client clicks on the advertisement and submits a request. This lead is uploaded to Roistat with the number of the visit.
-
A week later, the same client contacted the manager by phone. The manager manually created a deal and specified the same client, but left the roistat field empty. After that, the lead was uploaded to Roistat.
-
The visit number from the first client's lead will be automatically transferred to the second lead. Thus, in Roistat Analytics, these leads form a chain of visits.
Please note:
Only the visit number from the first deal is used. If there is no visit number in the first deal (for example, the deal was created manually), but it is known in the next deal, add this visit number to the first deal manually. Then all subsequent deals of this client will receive the visit number added to the first deal.
Lead Hunter¶
Do not normalize phone numbers from Lead Catcher¶
If this option is disabled, all telephone numbers obtained through the Lead Hunter form are normalized to the XXX XXX XX XX
format.
Example:
You are an international business owner. The site visitor opened the Lead Hunter and wrote a phone number in the Polish format: 06 001 60 90
. If the option is disabled, when creating a deal, Roistat will format the number and send it as +456 001 60 90
(code 45 is added instead of 0).
Enable this option to send such numbers in the format that the visitor used when filling out the form.
Do not check for duplicates in the Lead Hunter form¶
By default, the Lead Hunter form does not send duplicate leads to the project.
The text that will be spoken to the manager during call back¶
Specify the text if you want to change the standard message that the robot says to the manager when they call back. You can use Roistat variables.
Multi-Channel Analytics¶
Track multi-channel orders until they are paid¶
Enable this setting if you want to see which advertising channels resulted in a sale. When this setting is enabled, in the deal card, you will see the chain of visits that led to the sale, and not just the deal. This can be useful if you need to understand which channels are driving customers and which are driving sales.
If the setting is enabled, multi-channel chains will be separated by the sale date, and not the deal creation date.
Example 1: the client made several visits that led to one sale
The client went to the site through Channel 1, then went to the same site through Channel 2 and created a lead. After that, he once again went to the site through Channel 3, after which a sale was made on that lead:
visit 1 → visit 2 → lead 1 → visit 3 → sale from the lead 1
Without enabling the setting, the chain of visits will look like this:
visit 1 → visit 2
If the setting is enabled:
visit 1 → visit 2 → visit 3
Example 2: the client made several visits that resulted in several sales
The client went to the site through Channel 1, then again through Channel 2, and after that he immediately made a purchase. After some time, the client again went to the same site through Channel 3 and made a second purchase:
visit 1 → visit 2 → lead 1 → sale from the lead 1 → visit 3 → lead 2 → sale from the lead 2
In this case, even with the experimental feature turned on, the chain of visits is formed only for the first sale, and only one source will be specified for the second sale (visit 3). This is because the experimental feature allows linking visits only up to the moment of sale.
Analytics data¶
Use deals from earlier integrations¶
If you enable this option, deals from the previously used CRM will not be deleted from Roistat and will be displayed in Analytics. Do this if deals are not transferred from the previously used CRM to the new one.
Please note:
This option must be enabled before integrating with the new CRM.
Do not delete the last slash in visit pages' addresses¶
When saving the landing page, Roistat removes the last slash, and the site address from site.com/ turns into site.com. This can lead to an error in troubleshooting ("No tracking code was found on the site.com website / an error occurred").
Enabling the option allows you to fix the problem in diagnostics. After enabling the option, wait for 3-4 days, as the troubleshooting feature checks the page addresses for the last 3 days.
Exclude deals with 0 revenue from potential revenue calculation¶
If you use this experimental feature, no revenue will be calculated for deals with zero revenue.
Always show the hundredths of a share for the analyst's interest rates¶
Enable the setting if you want to track the change in hundredths of multi-channel analytics indicators without rounding the result.
Always show the hundredths of metrics for multi-channel analytics¶
Enable this option to always see hundredths for percentage indicators in analytics tables: conversions, ROI, CTR, shares, etc.
In the period comparison table calculate the change of percentage metrics in relative values¶
In the period comparison table, the percentage change is calculated as an absolute value using the formula value2 - value1
. Enable this setting if you want percentages to be calculated in relative terms using the following formula: (value2 - value1) / value2
.
Pairs of roistat tags and cities if you want to bind a city to the advertising channel¶
If certain advertising channels are strictly associated with the city, specify these pairs in this setting. Enter the value in the following format: channel_ny=New York,channel_bn=Berlin
.
Names of CRM fields from which you want to generate reports¶
When uploading deals, there is a limit on the number of characters in additional fields. If the limit is exceeded, some of the information will not be loaded, so some values will not be included in the Roistat analytics, and it will not be possible to build a report on them. Specify the ID of additional fields from CRM so that they have priority when uploading to analytics.
Pairs of web pages and advertising channels for which you do not need to record individual visits if the visitor has already been on the website¶
For example, if you want to exclude branded keywords from SEO to the main page for repeat visits, specify them in the following format: site.com/landing=seo,direct;site.com/landing2=seo
.
The maximum amount of days of the deal’s cycle¶
The setting allows you to include long-time deals in reports by the date of sale. Increasing the period can significantly slow down the loading of reports. The maximum value is 1095 days.
Custom U-Shape Attribution Model¶
Specify the new U-Shape-based attribution models that you want to see in analytics reports in the following format: A, B, N, Y, Z = attribution model name
. A and B will be equal to the weights of the first two sources, Y and Z will be equal to the weights of the last two sources, and the weight N will be distributed evenly among the remaining sources. The number of weights specified in the model must be 3 or 5. The weights are specified as values from 0 to 1 and must add up to 1. That is, the 50% weight will be specified as 0.5. For example: 0.5, 0.3, 0.2.
More about attribution models.
Don't send weekly reports to email¶
By default, Roistat sends weekly report to the account owner's email. Enable this option to not send reports to email.
Show marker level 3 for requests from SEO¶
Enable this setting if you want to see level 3 data in the SEO channel. This will come in handy if you have deals or visits with such a marker. For example, calls to static call tracking from turbo pages, where the marker may look like this: seo_yandex_turbo-page-1.
Do not round up pennies in monetary indicators¶
By default, Roistat rounds monetary values to integer values. Use this option to have all monetary indicators in Analytics reports (Revenue, Profit, CPL, etc.) shown to the nearest penny.
Spam leads¶
Do not send leads to CRM without contact details and comment¶
Leads with an empty phone number, email and comment will be marked as spam and will not be sent to CRM.
Do not send leads to CRM if comment contains these phrases¶
Specify the phrases that should not be contained in the comments of the lead. Each phrase must be entered on a new line.
Do not send leads to CRM if contact name contains these phrases¶
Specify phrases that should not be included in the contact's name. Each phrase must be entered on a new line.
Do not send leads to CRM with these emails¶
Each email must be entered on a new line. Only deals loaded since this option was enabled are taken into account.
Do not send leads to CRM if the phone contains numbers¶
Use this setting if you do not want leads with certain phone numbers to be sent to CRM.
- You can specify both the full number and part of the number (at least 4 characters). Leads with numbers containing the specified numbers will not be sent.
- Each phone must be specified on a new line.
- Full numbers can be specified in the following formats:
74951111111
,7(495)1111111
,+74951111111
or+7(495)1111111
. - Use the
*
character to indicate that other characters may appear before/after the specified sequence of digits.
Examples of using:
- Do not send leads with numbers that end in 1234:
*1234
- Do not send leads with numbers starting with 7985:
7985*
- Do not send leads with numbers containing 1234 in any of its parts:
*1234*
- Do not send leads with a number that completely matches 79851234567:
79851234567