In Mailchimp is I click on a user I can see which group they belong to under the details tab but I can't see which segment they belong to. Is there a way to check which segment they are in?
Also is their a difference between customer groups & groups?
As some users are in a customer group (i.e. General, Wholesale, Retailer, Not Logged In) which are not in the list of groups we created under manage list.
There is no way to check what segment someone is in based on their profile. Segments are what you create to organize your subscribers. You can create segments based on group criteria to keep track of what user is in what segment, but you can't directly see each segment a subscriber is in. A subscriber can be in an infinite number of segments, and some segments can even be created on the fly when setting up a campaign.
I'm not sure I can answer the second part of the question. I don't think customer groups is something native to Mailchimp. Perhaps it's a merge tag you created? These would be used in signup forms and in the body of your emails.
Related
I am looking for a very quick solution to solve the following problem:
On a web server it should be possible that a user can vote there for another user. So one user can always vote for another. This happens by sending a POST /vote/:id. This vote must now move into a list from all already made votes of other users.
This list of the ranking of the already voted users, should then put the user with the most votes on place one. The one with the second most votes on place 2 and so on.
Currently I use Redis for this and save the selected user id in a hash for each user id.
My problem now is to find out in this ranking list of the elected users, to which place now one or more users must be moved, whenever a new election arrives.
How can I know on which number to place the user that has just been elected, out of all those already elected?
What is the fastest and most efficient solution for this?
Currently I was thinking of a Redis List that would then allow me to record the placement with the user id and then filter by that. But is a complexity of O(n).
Let’s assume I’m in the context of an admin panel for a webshop. I have a list of orders. Those orders are payed for and are ready to ship. The (admin) user would like to start making shipments based on the items ordered.
Imagine there are 2 microservices. One for orders and one for shipments. In order to create a shipment, i will send a request with a couple of items to be shipped and an order ID to the shipment service. The shipment service will then check whether the items are present in the order by querying the order service. Because i don’t want to create a shipment with items that are not present in the order.
I’d like to have immediate consistency because the shipment data will be send to a third-party application after creation. Thereby it also feels weird to allow shipments to be created if the data is not correct.
I’m also using GraphQL mutations. Which means i have to return the updated state to the user, which also makes eventual consistency a lot harder.
What is the recommended approach for these situations? Could this be a sign that these 2 microservices need to be merged? I can imagine this situation can occur multiple times.
Is any clean way to hide an area from the sitemap, other than reviewing many role privileges one by one and remove privilege completely. I would be ok with amount of work just that there is no one-to-one correlation between the privilege and the menu item and more important, is the fact some of the privileges has many ramifications and I don't want to affect existing functionality. It would be hard to track bugs in this case.
This has to start with the logical grouping of necessary working entities (SubArea) under right Group, and ideally hence the main Area.
Let's say for example - Sales area should have Managers and Reps as Groups then classify the sub-areas for them individually for their needed entities. Then the navigation can be regulated with the help of identifying privileges specific for each persona and the navigation items can be controlled which hide the Group from others. Read more
Or if it is tough to identify such dedicated persona privilege, then create a dummy entity just for sitemap regulation without breaking any existing implementation.
In UCI app world, you can spin a new App for each persona, so silo app with own sitemap and logical groups the way you want.
I making a mobile app similar to facebook as a college project. Problem I am facing is say if I have 25 users and 24 users posted something on the site of which user1 made the first post. Now say the 25th user logs in after two days. Initially I was showing the feeds in FIFO order. But if I keep using FIFO, 25th user wont be able to see the last post unless he has undergone all the previous posts first. Same situation in LIFO. If we scale up the app, the problem statement would be huge as there would be some feeds which will never be seen. So how do I tackle this?
I thought of distributing users into groups and show the feeds within the groups first, and then to the neighbouring group and so on.
PS: I am using meteorjs for building the app.
So I have distributed the users into groups. I have attached a tag with every feed saying user from which group posted it.
Now I sort the feeds according to date-time at which they were created. Then I group them according to their user groups. Then I sort the feeds according to the no.of views (sorting within the group only).
Now I keep the sorted data as a list. To show the feeds to the user, I am trying to use trees. Say a user belonging to group 4 logs in. So I would use the group 4 data as node and create a binary tree. Then I would show all the feeds in the head first, then do a bfs traversal to show the feeds on the leaves.
Is there any other better method to make sure that every feed is seen atleast once by any user
So what I could think of is that you can divide the users into groups firstly. Then show the feeds from the same group. But show only new feeds here. Then show the feeds from neighbouring groups and move on. Then show the old feeds in the same manner.
I have been writing an Square Connect integration that rests on the fact that an item has one and only one ID, even when it is present in multiple locations. After testing with a subset of products on a separate Square account/App, things were working smoothly. I have now pointed the integration at the "real" Square account/App, using that account's credentials, which contains the same subset of products in addition to many others, and the integration is failing. It seems I have many items that now have a unique ID for each location. This means that a single item has multiple IDs. The item only displays once in the Square dashboard, but there are two unique IDs associated with it. In fact, I have one item that has two IDs, yet those IDs share a single variation ID.
I have also noticed two different formats of IDs, which from my research sounds like a variation due to information created pre- and post- a certain date.
Format 1: XXxXxXXX-xxXX-XxXx-XXX-XXXxxxxxxxXX
Format 2: XXXXXXXXXXXXXXXXXXXXXXXX
I suppose the first question is, is this normal behavior? And if not, any thoughts on what might be causing it and is there a way out of it?
There are some nuances to items with older accounts. Items were originally scoped to a location, which doesn't quite make sense with larger multi-location businesses. Internally we are migrating to a location independent item catalog, which should be invisible to you as an end user (save for the change in formats, like you mentioned) and depending on the date of your account it might have a mix of "old" and "new" item ids. It seems like you have basically a "new" location and an older one.
Basically in our current model you are only guaranteed that items will have unique ids within a location. We are working on new APIs that will allow you to manipulate items across locations more easily.