{"_id":"55781fe35129590d003ff503","githubsync":"","version":{"_id":"55781fe25129590d003ff4f7","project":"54aa7f773b56130b0056c86e","forked_from":"54aa7f773b56130b0056c871","__v":6,"createdAt":"2015-06-10T11:30:42.700Z","releaseDate":"2015-06-10T11:30:42.700Z","categories":["55781fe35129590d003ff4f8","55781fe35129590d003ff4f9","55781fe35129590d003ff4fa","55781fe35129590d003ff4fb","55781fe35129590d003ff4fc","55781fe35129590d003ff4fd","55781fe35129590d003ff4fe","564bbc7e8841060d00abb2ee","565b66c446118c0d00dcb0bb","56898269f8dc340d00308c13","582318b23b961a0f009516a1","594a848c9f4771001a43c959"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"Developers","version_clean":"2.0.0","version":"2.0"},"user":"54aa7f3f9bb00c0b00cb899b","__v":0,"category":{"_id":"55781fe35129590d003ff4fd","pages":["55781fe35129590d003ff503"],"version":"55781fe25129590d003ff4f7","__v":1,"project":"54aa7f773b56130b0056c86e","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-01-05T12:45:04.262Z","from_sync":false,"order":6,"slug":"faq","title":"FAQ"},"parentDoc":null,"project":"54aa7f773b56130b0056c86e","updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-01-05T12:51:49.545Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Why will users who are using an app with an SDK version below 2.8.0 not receive non feed card campaigns?\"\n}\n[/block]\nThe ability to send a push notification or an in app notification that links a user directly to a non card destination such as a deeplink or URL was added in version 2.8.0 of the Android and iOS SDK. Previously, all Pulsate campaigns had to link directly to a card in the Message Center. For this reason, users who are using an app with an SDK version that is lower than 2.8.0 will not be able to display non feed card campaigns.\n\nFor more information on sending a push notification that opens a deeplink, url or your app click [here](https://pulsate.readme.io/v4.0/docs/push-notification-campaigns). To find out about using In App Notifications to direct users to a deeplink, url or open your app, click [here](https://pulsate.readme.io/v4.0/docs/scheduling-advanced-options)\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"What happens to users inside a segment if they change their behaviour?\"\n}\n[/block]\nSegments are dynamic, meaning that the users can drop in and out of segments in real-time based on changes in their behaviour or location. So for example, if you build a segment today and there are 1,500 users that match the criteria you have set, it might not be the same number of users the next day, it fluctuates in real time.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Can I edit a campaign after I send it?\"\n}\n[/block]\nNo, once you have sent a campaign its sent there and then and you cannot edit it. Please ensure you review your campaign before sending it. In future releases we will be offering a 'scheduling' feature, meaning that you can set advanced dates for the campaign to run on, in this case we will allow you to edit the campaign as long as it has not been dispatched.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"How is the location feature in the segment builder different to geofences?\"\n}\n[/block]\nIn the segment builder, adding the location condition allows you to target users that are loosely within a given area. They are either there right now, or were last seen in that area. Location targeting in the segment builder works better for large areas, such as an entire town or city, or areas within a city. \n\nGeofenceing is a totally separate feature to location targeting and has a number of key differences: Geofencing is not used for targeting users that are in a location 'right now' but rather a virtual perimeter that is setup in advanced of users coming within rage of it. \n\nSo for example, if you setup a geofence around your store, users will get a campaign when at some point in the future they walk into the geofence or leave it (whichever you decide). Geofencing generally is for much smaller areas usually somewhere between 100-1000 meters.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"How long do users get geofence alerts for?\"\n}\n[/block]\nCustomers will keep getting geofence alerts every time they enter the geofence. We know, we need to think harder on this one! We're working on it.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Is there a limit to the amount of geofences I can add to a campaign?\"\n}\n[/block]\nNo, you can create as many geofence as you like. Tip try not to have overlapping geofences or geofences that are very close to one another and this can create confusion for both Pulsate and customers alike. As a general rule of thumb keep geofences at least 500 meters apart.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Why doesn't my geofence work?\"\n}\n[/block]\nGeofencing is only compatible from iPhone 4 and above, all older models of the iPhone do not support this feature in Pulsate.\n\nAs we rely on highly variable parameters from users devices, results when using geofences can sometimes differ. Occasionally geofences will not trigger or they trigger too late, this can be due to very inaccurate data being sent back by the device (over which we have not control). Some users (a minority) keep all location services on the device turned off due to privacy concerns meaning geofencing does not work at all. \n\nGeofences can also fail to trigger if you have made the geofence too small, for example a 10 meter fence is a narrow window for us to target within, and in the situations where we can target it successfully, the users device is using GPS data. If we are trying to target a 10 meter geofence and we are only receiving low accuracy cell tower data from the device its a shot in the dark. Hence we recommend making your geofences larger, start with 100 meters as a guide line.\n\nAnother problem with smaller geofences is that for us to recognize that the geofence has been crossed the user must cross the geofence boundary and remain inside the geofence for 10 seconds. A user is unlikely to remain inside a 10 meter geofence for 10 seconds if walking throughout it. We impose a 10 second rule before the trigger event fires, which avoid spurious on_entry on_exit events for users travelling along side a geofece.\n\nIn rare cases a geofence might trigger slightly before the user crosses the boundary threshold, this can be down to location accuracy of the device, factors include: if GPS/WiFi are toggled on or off on the device, strength of network connection can also be a contributing factor.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"What size should I make my Geofences?\"\n}\n[/block]\nWe recommend 100 meters or larger for optimal results (but not exceeding 1000 meters). We have seen situations where you will still get an 80% success rate at 50 meters and smaller, but as we rely on a combination of GPS, BTS and ambient WiFi data to determine if a user has crossed a geofence boundary results may vary. \n\nResult vary as a users device may have GPS / WiFI tuned off, or might be a quite a distance from the nearest cell tower which can cause accuracy problems, generally in urban areas we have had a 98% success rate when testing geofences of 100 meters and larger.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"How much location data does Pulsate store and for how long?\"\n}\n[/block]\nWe store every piece of location data that a users device transmits back to the Pulsate platform, this depends on how often they move about or change location. On average we track 50   location data points per user per 24 hours. For the moment our plan is to store this data indefinitely.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Does location tracking wear down my customers battery?\"\n}\n[/block]\nNo, we have tested this extensively. Our proprietary geolocation  technology which is a part of the Pulsate SDK uses new methods of retrieving highly accurate location data while have zero impact on battery life. Not convinced? Implement our SDK, test it out, and see for yourself.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"How do we track users location?\"\n}\n[/block]\nWe track users location by using various on board radios on the device, we use a combination of GPS, BTS (cell tower) and ambient WiFi data. \n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Why is social data missing or incorrect?\"\n}\n[/block]\nIn order for us to augment customer records with additional social data and avatars you need to pass us the email address of that user via the SDK, this is simple if your App users are authenticated within your App. If all of your App users are anonymous, Pulsate will not be able to augment their record with additional social data. \n\nIn the future if you are able to obtain the users email address you can always pass this to Pulsate as an updated customer record and we will then make an attempt to fetch social data for that customer.\n\nIn certain situations you may have passed an email address of a customer to Pulsate and we have been unable to retrieve any useful information about that user, or in some cases it might be  incorrect. In the first situation the email address you could be passing might be someones 'work' email address, all of their social accounts could be connected to a 'personal' gmail / yahoo address that you are unaware of. \n\nIn the second scenario you could have passed a valid 'personal' email account that is connected to various social accounts and still we cannot pull the correct data. Our provider (Fullcontact.com) make a best effort attempt to pull correct data, but in some rare situations it fails.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Where does the social data come from?\"\n}\n[/block]\nSocial data is obtained through our partner (fullcontact.com) they provide an API service by which we pass each email address through, they then connect to various social networks to freely obtain publicly available information associated with that address.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"How secure is my data?\"\n}\n[/block]\nWe use bank grade security, implementing 256-bit encryption, secure socket layers and firewalls to keep your data safe and secure.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Where does Pulsate store data?\"\n}\n[/block]\nWe store all data securely on the Amazon cloud within their EU data centre which is located in Ireland.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"What data does Pulsate collect and store concerning my customers?\"\n}\n[/block]\nPulsate collects a range of data on your customer, we are a 'data processor' (under Irish law - data protection act) and the onus is on you as the 'data controller' that you have express permission from your customer to use and send this data to Pulsate. \n\nGenerally speaking, Pulsate collects ALL of its data anonymously unless you explicitly decide to pass the email address or name of that customer to Pulsate. To get the best out of Pulsate, we do recommend that you pass email address / name if they are available within your mobile application.\n\nPulsate collects the following system parameters:\n\n- Name (optional)\n- Email (optional)\n- Date and time last seen\n- Sign up date\n- Number of sessions\n- Timezone\n- Operator\n- Connection Type\n- Device token\n- IP address\n- Device type\n- Location\n\nIf you pass an email address, we will attempt to fetch and store the following additional parameters:\n\n- Avatar (image of customer)\n- Full name\n- Links to social media profiles\n- Number of twitter followers\n- Klout score\n\nAdditional data is obtained through our partner (fullcontact.com) they provide an API service by which we pass each email address through, they then connect to various social networks to freely obtain publicly available information associated with that address.","excerpt":"","slug":"common-questions","type":"basic","title":"Frequently asked questions"}

Frequently asked questions


[block:api-header] { "type": "basic", "title": "Why will users who are using an app with an SDK version below 2.8.0 not receive non feed card campaigns?" } [/block] The ability to send a push notification or an in app notification that links a user directly to a non card destination such as a deeplink or URL was added in version 2.8.0 of the Android and iOS SDK. Previously, all Pulsate campaigns had to link directly to a card in the Message Center. For this reason, users who are using an app with an SDK version that is lower than 2.8.0 will not be able to display non feed card campaigns. For more information on sending a push notification that opens a deeplink, url or your app click [here](https://pulsate.readme.io/v4.0/docs/push-notification-campaigns). To find out about using In App Notifications to direct users to a deeplink, url or open your app, click [here](https://pulsate.readme.io/v4.0/docs/scheduling-advanced-options) [block:api-header] { "type": "basic", "title": "What happens to users inside a segment if they change their behaviour?" } [/block] Segments are dynamic, meaning that the users can drop in and out of segments in real-time based on changes in their behaviour or location. So for example, if you build a segment today and there are 1,500 users that match the criteria you have set, it might not be the same number of users the next day, it fluctuates in real time. [block:api-header] { "type": "basic", "title": "Can I edit a campaign after I send it?" } [/block] No, once you have sent a campaign its sent there and then and you cannot edit it. Please ensure you review your campaign before sending it. In future releases we will be offering a 'scheduling' feature, meaning that you can set advanced dates for the campaign to run on, in this case we will allow you to edit the campaign as long as it has not been dispatched. [block:api-header] { "type": "basic", "title": "How is the location feature in the segment builder different to geofences?" } [/block] In the segment builder, adding the location condition allows you to target users that are loosely within a given area. They are either there right now, or were last seen in that area. Location targeting in the segment builder works better for large areas, such as an entire town or city, or areas within a city. Geofenceing is a totally separate feature to location targeting and has a number of key differences: Geofencing is not used for targeting users that are in a location 'right now' but rather a virtual perimeter that is setup in advanced of users coming within rage of it. So for example, if you setup a geofence around your store, users will get a campaign when at some point in the future they walk into the geofence or leave it (whichever you decide). Geofencing generally is for much smaller areas usually somewhere between 100-1000 meters. [block:api-header] { "type": "basic", "title": "How long do users get geofence alerts for?" } [/block] Customers will keep getting geofence alerts every time they enter the geofence. We know, we need to think harder on this one! We're working on it. [block:api-header] { "type": "basic", "title": "Is there a limit to the amount of geofences I can add to a campaign?" } [/block] No, you can create as many geofence as you like. Tip try not to have overlapping geofences or geofences that are very close to one another and this can create confusion for both Pulsate and customers alike. As a general rule of thumb keep geofences at least 500 meters apart. [block:api-header] { "type": "basic", "title": "Why doesn't my geofence work?" } [/block] Geofencing is only compatible from iPhone 4 and above, all older models of the iPhone do not support this feature in Pulsate. As we rely on highly variable parameters from users devices, results when using geofences can sometimes differ. Occasionally geofences will not trigger or they trigger too late, this can be due to very inaccurate data being sent back by the device (over which we have not control). Some users (a minority) keep all location services on the device turned off due to privacy concerns meaning geofencing does not work at all. Geofences can also fail to trigger if you have made the geofence too small, for example a 10 meter fence is a narrow window for us to target within, and in the situations where we can target it successfully, the users device is using GPS data. If we are trying to target a 10 meter geofence and we are only receiving low accuracy cell tower data from the device its a shot in the dark. Hence we recommend making your geofences larger, start with 100 meters as a guide line. Another problem with smaller geofences is that for us to recognize that the geofence has been crossed the user must cross the geofence boundary and remain inside the geofence for 10 seconds. A user is unlikely to remain inside a 10 meter geofence for 10 seconds if walking throughout it. We impose a 10 second rule before the trigger event fires, which avoid spurious on_entry on_exit events for users travelling along side a geofece. In rare cases a geofence might trigger slightly before the user crosses the boundary threshold, this can be down to location accuracy of the device, factors include: if GPS/WiFi are toggled on or off on the device, strength of network connection can also be a contributing factor. [block:api-header] { "type": "basic", "title": "What size should I make my Geofences?" } [/block] We recommend 100 meters or larger for optimal results (but not exceeding 1000 meters). We have seen situations where you will still get an 80% success rate at 50 meters and smaller, but as we rely on a combination of GPS, BTS and ambient WiFi data to determine if a user has crossed a geofence boundary results may vary. Result vary as a users device may have GPS / WiFI tuned off, or might be a quite a distance from the nearest cell tower which can cause accuracy problems, generally in urban areas we have had a 98% success rate when testing geofences of 100 meters and larger. [block:api-header] { "type": "basic", "title": "How much location data does Pulsate store and for how long?" } [/block] We store every piece of location data that a users device transmits back to the Pulsate platform, this depends on how often they move about or change location. On average we track 50 location data points per user per 24 hours. For the moment our plan is to store this data indefinitely. [block:api-header] { "type": "basic", "title": "Does location tracking wear down my customers battery?" } [/block] No, we have tested this extensively. Our proprietary geolocation technology which is a part of the Pulsate SDK uses new methods of retrieving highly accurate location data while have zero impact on battery life. Not convinced? Implement our SDK, test it out, and see for yourself. [block:api-header] { "type": "basic", "title": "How do we track users location?" } [/block] We track users location by using various on board radios on the device, we use a combination of GPS, BTS (cell tower) and ambient WiFi data. [block:api-header] { "type": "basic", "title": "Why is social data missing or incorrect?" } [/block] In order for us to augment customer records with additional social data and avatars you need to pass us the email address of that user via the SDK, this is simple if your App users are authenticated within your App. If all of your App users are anonymous, Pulsate will not be able to augment their record with additional social data. In the future if you are able to obtain the users email address you can always pass this to Pulsate as an updated customer record and we will then make an attempt to fetch social data for that customer. In certain situations you may have passed an email address of a customer to Pulsate and we have been unable to retrieve any useful information about that user, or in some cases it might be incorrect. In the first situation the email address you could be passing might be someones 'work' email address, all of their social accounts could be connected to a 'personal' gmail / yahoo address that you are unaware of. In the second scenario you could have passed a valid 'personal' email account that is connected to various social accounts and still we cannot pull the correct data. Our provider (Fullcontact.com) make a best effort attempt to pull correct data, but in some rare situations it fails. [block:api-header] { "type": "basic", "title": "Where does the social data come from?" } [/block] Social data is obtained through our partner (fullcontact.com) they provide an API service by which we pass each email address through, they then connect to various social networks to freely obtain publicly available information associated with that address. [block:api-header] { "type": "basic", "title": "How secure is my data?" } [/block] We use bank grade security, implementing 256-bit encryption, secure socket layers and firewalls to keep your data safe and secure. [block:api-header] { "type": "basic", "title": "Where does Pulsate store data?" } [/block] We store all data securely on the Amazon cloud within their EU data centre which is located in Ireland. [block:api-header] { "type": "basic", "title": "What data does Pulsate collect and store concerning my customers?" } [/block] Pulsate collects a range of data on your customer, we are a 'data processor' (under Irish law - data protection act) and the onus is on you as the 'data controller' that you have express permission from your customer to use and send this data to Pulsate. Generally speaking, Pulsate collects ALL of its data anonymously unless you explicitly decide to pass the email address or name of that customer to Pulsate. To get the best out of Pulsate, we do recommend that you pass email address / name if they are available within your mobile application. Pulsate collects the following system parameters: - Name (optional) - Email (optional) - Date and time last seen - Sign up date - Number of sessions - Timezone - Operator - Connection Type - Device token - IP address - Device type - Location If you pass an email address, we will attempt to fetch and store the following additional parameters: - Avatar (image of customer) - Full name - Links to social media profiles - Number of twitter followers - Klout score Additional data is obtained through our partner (fullcontact.com) they provide an API service by which we pass each email address through, they then connect to various social networks to freely obtain publicly available information associated with that address.