Hello FullCalendar team,
I am looking to build a feature that would limit the type of events that could go into a specific timeslot.
For example, I would like to indicate to a front-desk end-user that only a certain type of appointment was allowed to be entered into the timeslot. Perhaps the timeslot only takes meeting types that are tagged "check-ins" and "follow-ups" arbitrarily set by some higher up admin.
What would be the best way to go about building this limitation and displaying it to the user? I saw that there is an overlap function I might be able to use along with background-events. The higher-up admin might be able to create background-events that if they overlap with another requested event then limits the type. THen it would be very clear that any certain color-coded event set by the higher-admin would indicate that only certain types could be added.
But am I missing a very obvious way to do this? I was hoping there might be an easier way to templatize the day for end-users. Appreciate the advice.
Trying to create a simple segment to excludes a referral source retrospectively (a spam site called trafficbot.link) from all analytics views.
I can:
…set Traffic Sources > Source > contains / starts with / exactly matches, and it will correctly show ONLY the spam/fake accesses (the percentage of users and sessions on the right is refreshed in real time).
I can't:
…do it the other way around, i.e. use does not contain / does not exactly match / is not one of.
The total stays stuck on 100% of sessions.
Am I missing something obvious?
I note this answer which has no input other than from the original questioner, suggesting Google say it's "not possible" to exclude existing requests - surely it is? Isn't that the whole point of segments? How are you supposed to filter out spam otherwise?
(I'm aware analytics filters isn't retrospective.)
You are talking about segments but the link you entered refers to filters.
Anyway, retroactively you can apply a segment to see the data without the spam one, you can use an advanced segment, choose conditions and exclude sessions that contain for example browser size equal to (not set).
https://www.fortop.it/journal/tieni-lontano-lo-spam-dai-dati-google-analytics/
Stackdriver logs search is great for finding particular logs one might be interested in, but then it's a bit annoying to zoom out and look at nearby logs e.g. what was happening around that time, especially if a lot of logs were generated on/near the same timestamp. Kibana has a feature for being able to see nearby docs[1] and apply/takeaway filters, is there a way to do this in Stackdriver?
[1] https://youtu.be/sNGbxbCv-6I
There are some basic filters available in Stackdriver which may not exactly what you see in Kibana but would serve your purpose. You can use the time-range selector drop-down menu to filter specific date and time in the logs. Once you identify a specific log, you can set time to see logs before and after using the "custom" field of time range selector.
Alternatively, you can set "Jump to time" field from the time-range selector field and then set time for specific log and then you could use another drop-down menu next to the time-range selector from where you can select time ranges (Eg. +/-1 Hour, +/-6 hours etc).
I'm not getting the right results returned for a goal I have set up. The goal says the last 7 days have 92 goal conversions, when it should be 400+.
When a user completes a subscription purchase, they land on a confirmation page. We have several subdomains that the user can be coming from as well as the potential for a reference appended to the URL. So, I have the goal set up as a regular expression like this:
.*/insider/confirm.*
If, for example, the user pays and then is directed to the following page, shouldn't the goal be recorded?
test.com/insider/confirm?ref=2343
As I can't see anything wrong with the regular expression, although very greedy, the goals should be captured with the above example URL and goal setup.
Have you recently set this goal up? A thing with goals are that they aren't historically applicable to your data. They start collecting data from the point where you set it up.
Have you tried using the above regexp in the "All pages"-report under "Behavior"? Enter it into the filter pattern and there you can see exactly what pages your regexp would capture.
I have a client which is shipping via UPS, and therefore cannot deliver to Post Office boxes. I would like to be able to validate customer address fields in order to prevent them from entering addresses which include a PO box. It would be best if this were implemented as a regex so that I could use a client-side regex validation control (ASP.NET).
I realize there's probably no way to get a 100% detection rate, I'm just looking for something that will work most of the time.
UPS also has tools that you can integrate to do this... that way you can verify an address exactly as to whether or not they will ship, what the cost would be, schedules, etc. I suggest visiting the UPS IT Solutions page for more information.
This should get you started. Test to see if the Address field matches this regex.
"^P\.?\s?O\.?\sB[Oo][Xx]."
Translation to English: That's a P at the beginning of the line, followed by an optional period and space, followed by an O, followed by an optional period, followed by a space, followed by "Box", followed by anything else.
You might be better off putting a disclaimer on the page warning that you can not ship to post office boxes, opposed to validating the input.
More than likely if you do create a regex that catches most of the P.O. Box scenarios, there's a good chance it'll also catch things you weren't intending (i.e. a customer with a street name containing the letters 'p' 'o' and 'box')
Unfortunately, UPS's online software allows P.O. Boxes to go through, but will choke on them once they're in the shipping channel.
In our case, our cart abandonment rate went up when we tried to gracefully prevent P.O. Boxes. We found it much more cost effective to leave it alone, accept the sale, bring it to the attention of customer service, and let them resolve it.
Of course, if you get a high incidence of P.O Boxes, this may not be the case for you.
I'd start with a regex ala Lizard (but use the "ignore case" flag :)), test on historical data, then iterate as you see what invalid inclusions and exclusions you see in testing.
Most shipping providers (for example FedEx) will validate the shipping address. For example, with FedEx web services, there is a call to validate a shipping address and get the estimated cost. This not only ensures that the address is not a PO Box, but also makes sure that the rest of the address is valid.
Regarding the OP's comment to Jason Coco's answer:
Since you're in a position to add regex validation to the shipping address, I assume that you have control of the application (i.e., you have the source and can modify it). If that's the case, then you should have the ability to, on reciept of the submitted data, check whether it is to be shipped via USPS, FedEx, or UPS and submit a request to the appropriate shipper-specific address validator, gaining all the benefits suggested in Jason's answer.
By making it shipper-specific, this would also allow you to avoid implementing one-size-fits-all rules, such as "no PO boxes because UPS doesn't deliver to them", even though the user can select non-UPS shippers who do deliver to PO boxes.
What if it doesn't start with "PO Box.." or "P.O. Box" ?
Example:
John Schmidt |
Silver Valley PO Box 3901 |
Whereswaldoville, SI. 78946
I used an onblur event for the address field to use a javascript function, indexOf, to recognize the input.toUpperCase "PO BOX" || "P.O" that is >= 0.
If either of these two searches are not found, the return is -1, otherwise, it will return the string's start position which will always be 0 or more.
This will ensure that lazy typing, 'po box,' 'p.o box,' and as well as 'p.o. box' will be recognized. I suppose you could add 'po. box' as well.
Anyway, the condition triggers an unobtrusive message to show that 'We can't ship to a PO Box address." It's a feature to not see it if it doesn't apply to you. Otherwise, for users who don't have js or css enabled, they'll just see the message. The only fail on this graceful degradation is if a user has css, but not js enabled (where they just won't see the message at all). I only came up with the solution today, but if I think of a better way, I'll come back to post it here.